Paul Moore wrote:
> Not 100% sure about this, but I'm fairly certain this is SELinux type
> enforcement issue. Have you tried adding some policy like the
> following:
>
> allow netlabel_peer_t netif_t:netif { ingress };
Nope, but sesearch comes up empty. In other news, same denial for
s0<->s0. So, you're right.
> The default setting is part of the SELinux policy using an "initial
> SID" and isn't something you probably want to modify. I would
> recommend using semanage to set the interfaces individually.
I don't think this is such a good idea. The rule should be "what's not
allowed, is denied". Now all interfaces that the user sticks in get
implicitly s0-s15 and, perhaps even worse, since they have to be
reconfigured from userspace, there would be a slight delay until that
happens, even if done by udev-launched script. Moreover, interfaces can
be labeled anyhow, so pre-semanaging eth0 through say eth99 is only a
partial solution, let alone clumsy.
Thus I would advocate for the default to be low.
> Dynamic permission checks. If you don't have any type of labeled
> networking configuration present the permission checks are disabled
> inside the kernel. It may seem odd right now, but trust me, this is a
> very good thing.
I agree, this is odd and brutally contra-intuitive. We're speaking about
egress checks (due to BLP) but we need to configure ingress labeling?
(And even of a fallthrough kind?) What's the reasoning behind this?
There's one more question, if I may. It appears to me that secmark and
netlabel, when confronted with normal (ie. non-CIPSO, etc) traffic,
provide redundant ways to label ingress packets. (Netlabel has fewer
options but it too operates on a per-packet basis.) Is this so, and if,
are there plans for unification?
Regards,
Michal Svoboda
Attachment:
pgpXtNpFrMUvo.pgp
Description: PGP signature
