Paul Moore wrote: > Well, keep in mind that once you label the interface via semanage, on > subsequent reboots it takes effect before the network is brought up > (it happens during policy load) so you don't really have to worry > about any race conditions. However, you do make a good point about > interface naming, but I would suspect that anyone who is interested in > running the strict/MLS SELinux policy is also tightly controlling > physical access to the machine and binding interface > names/configuration to the physical MAC address which means problems > caused by new or mis-named interfaces are not a real concern. There are also software interfaces like tunnels and taps, and god knows what else (you can even run a ppp interface over a ssh session). At some point it might just be that they are all pinned down and tightly controlled, but why have to do all this *just because* the default is systemhigh and not *in addition to* a sane systemlow default? Isn't a longish list of semanaged interfaces just a more volatile version of a low default? > So let me get this straight ... you are very concerned about what > information leaves your system over what physical network, but you > don't care at all about the information coming into your system? That > seems odd to me. The SELinux network access controls are dynamic and > assume that those who wish to use them want to enforce access controls > on traffic both leaving and entering the system. If you just want to protect confidential data in your box then strictly speaking yes! egress traffic is everything you need to worry about (at least network-wise). Second, I'm not quite sure if I understand why defining a *fallback* label is necessary to turn on the whole infrastructure. I think that the fallback label is not that much necessary in most situations. If I wanted to implement a MLS network then my first shot would be to designate a separate interface for s1 traffic. Thus my eth1 would have s1 and I wouldn't need a fallback label there. If I wanted to use single interface for multiple levels, I could use the CIPSO stuff to mark packets at the sender and yet again I would do without fallback labels at the receiver. (I would assume unmarked packets as invalid.) Only if I wanted to use a single interface for both unmarked and marked traffic I would need to define a fallback label. > This next point may sound minor, but trust me it is important: the > per- packet labels provided by secmark do not represent the same > security attributes as the per-packet labels provided by NetLabel (or > labeled IPsec for that matter). The secmark labels represent the IP > attributes of the packet, e.g. IP addresses, while the NetLabel and > labeled IPsec labels, called network peer labels, represent the > security attributes of the sender, e.g. apache_t. That's true only when the sender already fills in the netlabel info. My point was that netlabel fallback labels can be only configured per IP address, but secmark has the whole netfilter infrastructure behind it, thus could provide more fine-grained fallback labeling. Michal Svoboda
Attachment:
pgpQc0ElUvDZ4.pgp
Description: PGP signature
