On Thu, May 21, 2020 at 1:16 PM Paul Tagliamonte <paultag@xxxxxxxxxx> wrote: > On Wed, May 20, 2020 at 02:39:49PM -0400, Paul Moore wrote: > > Presumably it works when you are in permissive mode but fails when you > > are in enforcing mode, or does it fail in permissive too? > > That's correct, everything seems A-OK in permissive mode, and starts to > get denied (likely correctly) in enforcing mode. > > > If it works in permissive mode but you aren't seeing any AVC failures, > > you may want to try removing the dontaudit rules from the policy. You > > can do that via 'semodule -DB' (the semodule(8) manpage has some > > examples). > > Just tried that, thank you for the suggestion! I don't see any > additional logging, but I'm going to follow up more comprehensively > after reading the documentation. I'll give this a stronger go tonight. Okay, let us know what you find out. I'm a little concerned that you didn't see any additional AVC denials in the logs; if the system is working in permissive and you're not seeing any denials with the dontaudits removed something is off. > > You may find that in the near term you need something like Fedora's > > unlabelednet policy module which blanket allows unlabeled network > > traffic to all the domains on the system. > > Ah! This makes _so much_ sense. I was wondering where rules defining > this behavior lived. Looks like it's a (very comprenstive?) RH specific > changeset that we don't carry in Debian. I've got some work cut out for > me from the looks of it. The basic idea is that you have some type attribute which represents all the domains on the system and you grant that attribute the ability to talk to unlabeled traffic. Perhaps the Fedora patch might not be a direct fit, but I imagine you could do something very similar for Debian without too much difficulty (warning: I'm saying this without looking at the Debian policy). However, it is worth mentioning again that this approach allows unlabeled traffic *everywhere* and isn't really suitable for a system in a proper labeled network (it somewhat defeats the purpose of setting up labeling in the first place). > I started to graft sections I thought were relevent from policy-rhel-7.2-base.patch > into my local policies, but I think I'm super in over my head. This is > likely going to take me some time to work through, but it's monumentally > helpful. I was only looking at the upstream rules and our package, which > explains why I was missing a lot of this. > > I assume since this is being maintained by a lot of folks working > upstream too which makes me suspect this is a WONTFIX situation > with the upstream rules. Seems like I ought to tread lightly here. I'm not sure I would jump to the same conclusion. First the RHEL 7.x policy, like RHEL 7.x in general, is quite old; second, while we do regularly perform some basic labeled networking tests as part of the SELinux test suite, it definitely doesn't get the same level of everyday testing that other parts of SELinux receive. If you hit a problem you can't solve don't be afraid to speak up. Either it's something in your policy we can (hopefully) help you resolve, or it's a real bug in the system that we can (hopefully) get fixed for everyone. > > It's not clear which interface you sniffed, was it the loopback > > interface? > > I was sniffing from the VM Host (a laptop) to see what was coming in/out > of the network when I tried to initiate an SSH connection from the LAN > to the VM, since that *should* be unlabeled and pass through (although > given the bit above about the default unlabeled rules, it's likely > getting filtered out). Depending on the age of the kernel on your host, there *may* be issues with it passing CIPSO traffic properly, even if it isn't configured (there were bugs in older kernels that have since been fixed). However, since you're not sending CIPSO traffic outside the guest this shouldn't be an issue. > I was trying to minimally set up labeling for localhost (without > impacting the LAN NIC) to make a baby step in enabling NetLabel with > enforcement on, and still allowing network I/O except where I was > placing specific rules in place. If you want to take even smaller steps, you can combine the NetLabel domain and address selectors such that only specific apps/domains will send labeled traffic over loopback. * https://www.paul-moore.com/blog/d/2009/02/netlabel_address_selectors.html -- paul moore www.paul-moore.com
