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. > 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. 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. > 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). 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. > That is the only interface which should be doing any > explicit labeling; if you see CIPSO IP options on non-loopback > interfaces something is wrong. I would also expect you to see CIPSO > options on the loopback traffic, do you? I believe so, but I wasn't sniffing inside the VM because my SELinux rules need to be fixed :) It certently works in permissive mode, and I'd expect it works in enforcing mode, but it's tough to tell right now. I'll see if I can put a rule in place to start up a getpeercon daemon and see what it says. > As an aside, Wireshark does know how to parse CIPSO options so you > should be able to peek at them that way; although Wireshark does not > know about the "local" tag type we use on loopback (... and it > shouldn't, it's a horrible abuse of CIPSO, done intentionally <g>). Roger that :) > Try removing the dontaudit rules (above) and see if that helps with > the AVCs. Let us know what you find. Will do, I'll dig deeper, and come back with something a bit more specific. I think between that and the unlabelednet module, I've got some debugging to do. paultag -- .''`. Paul Tagliamonte <paultag@xxxxxxxxxx> : :' : Proud Debian Developer `. `'` 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 `- http://people.debian.org/~paultag
Attachment:
signature.asc
Description: PGP signature
