You are correct, we want to keep the existing overrides, but not provide
anymore overrides. The network interface / node checking rope should be
very short. The few exceptions of unlabeled_t or kernel_t. kernel_t was
necessary for nfs awhile back (may not be necessary now), probably
iSCSI, or basically things where the kernel is generating the packet
instead of a process and not assuming other credentials.
-Chad
>
> > In Solaris Trusted Extensions, neither the net_mac_read,
> > net_mac_write, nor net_repy_equal privileges are
> implemented. It was
> > viewed as a weakness in Trusted Solaris that MAC could be
> overridden by privilege.
> > Instead, the administrator (who configures the system
> network policy)
> > can enumerate multilevel network ports, and appropriately
> privileged
> > services can bind to them.
>
> I assume by multilevel network ports you are talking about
> port polyinstantiation and not a single (in every sense of
> the word) port that allows a range of labels?
>
> If we assume polyports then I agree that it makes perfect
> sense to try and work around the MLS constraints. I wonder
> about some privileged apps but I would need to think about
> that some more.
>
> > Since MLS constraints are relatively new to UNIX, there isn't a
> > compatibility requirement that the superuser should be able to
> > override it. So don't provide any more rope than you need to.
>
> Well, the MLS constraints aren't all that new to SELinux and
> several already exist in the networking space (the patch
> above didn't create any new ones, just used the existing
> constraints). As I understand it, the SELinux constraints
> are also quite different from the TSOL/TX privileges; I'll
> concede that they are both rope, but I think the lengths are
> quite different ;)
>
> Perhaps I'm missing something but I'm pretty sure that
> without any form of polyports (I highly doubt we will see
> these anytime soon) we are going to need/want network MLS
> constraint overrides.
>
On Friday 13 February 2009 05:17:13 pm chanson at trustedcs.com wrote:
> You are correct, we want to keep the existing overrides, but not provide
> anymore overrides. The network interface / node checking rope should be
> very short. The few exceptions of unlabeled_t or kernel_t. kernel_t was
> necessary for nfs awhile back (may not be necessary now), probably
> iSCSI, or basically things where the kernel is generating the packet
> instead of a process and not assuming other credentials.
Well, I suppose we can take the minimalistic, aka "short rope", approach right
now since the ingress/egress controls are still new and not really integrated
into policy in the form of templates. As we continue to develop the policy
and we find a need for them we can always [re-]add them. Unless anyone chimes
in over the weekend or next Monday I'll respin a patch next week.
Just out of curiosity, are you guys using any of the new stuff or are you
still using your own special kernel with the rejected network controls? I ask
because I would be curious about any feedback you might have on the new bits
in mainline.
--
paul moore
linux @ hp