Paul Moore wrote: > On Thursday 10 January 2008 1:56:32 pm Joshua Brindle wrote: >> Paul Moore wrote: >>> On Thursday 10 January 2008 10:32:10 am Chad Hanson wrote: >>>> These controls look good to us... >>> >>> Great. I'm assuming the lack of complaints means others are happy >>> with this as well. >> >> I haven't gotten around to looking at the rfc in detail but it looks >> like the secmark/external labeling concepts are being merged again >> when we already decided to keep them as separate systems. > > No, the secmark and peer/external labeling concepts are _not_ > being merged. The peer/external label will continue to > represent the label of the socket that sent the data (peer > label = firefox_t) while the secmark label will continue to > represent the packet's IP attributes such as port information > (secmark label = http_packet_t). Nothing has changed in this > regard and I don't expect it to anytime soon. > > I assume the source of confusion are the following permissions: > > - inbound forwaded traffic permissions > > # is apache allowed to forward web traffic through this system? > allow peer_t secmark_t:packet forward_in; > > - outbound forwarded traffic permissions > > # is apache allowed to forward web traffic through this system? > allow peer_t secmark_t:packet forward_out; > > In both cases we cannot use the socket's label as this packet > is neither generated by or consumed by a local socket (forwarded > traffic). However, we can still perform a meaningful secmark access > check by checking the secmark label against the peer label; > this is similar to how we check the secmark label against the socket > label for regular (non-forwarded) traffic. The key here is to > remember that > the peer label represents the original socket's label even > though in the forwarded case the socket happens to be located > on a different machine. > > Make more sense now? Sure, as long as the secmark label isn't mutating to accomidate forwarding checks it sounds reasonable to me. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
