* MCS NetLabel @ 2021-04-18 20:01 Paul R. Tagliamonte 2021-04-18 21:18 ` Paul Moore 0 siblings, 1 reply; 4+ messages in thread From: Paul R. Tagliamonte @ 2021-04-18 20:01 UTC (permalink / raw) To: SElinux list Hello SELinux folks, I'm running a test system using MCS and just starting to get to the point where I'm interested in enabling NetLabel + CIPSO to pass along context on a LAN. As a first step, I was able to get it working off `localhost` before adding in CIPSO or other boxen. I'm able to run in enforcing mode (amazing!) and get the peer context (even more amazing!) -- which I can use to calculate the effective "connection context" for logical filtering on common categories. That's really great! I'm a bit confused with some of the enforcement on this, though. When I run my server (with a user and binary at the level of `s0:c1`), connecting to localhost via a user at `s0` results in a connection getting established. While I understand this isn't the same as MLS / sensitivity level, I'm a bit surprised that it didn't refuse to connect to the privileged resource. Certainly I can't cat a file from a user at `s0` that's at `s0:c1`, or likely (I haven't tried, but it stands to reason) a UNIX Socket with `c1` -- so the TCP connection going through was a bit surprising. I can see in the peer context that the user is at `s0` (without `c1`), so it'd be possible to filter this software-side, but it'd also be a bit more of a mental relief if only processes with the `c1` category could connect. Is there any documentation on how to set that particular type of enforcement? Thank you all very much! Paul -- :wq ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: MCS NetLabel 2021-04-18 20:01 MCS NetLabel Paul R. Tagliamonte @ 2021-04-18 21:18 ` Paul Moore 2021-04-18 21:56 ` Paul R. Tagliamonte 0 siblings, 1 reply; 4+ messages in thread From: Paul Moore @ 2021-04-18 21:18 UTC (permalink / raw) To: Paul R. Tagliamonte; +Cc: SElinux list On Sun, Apr 18, 2021 at 4:02 PM Paul R. Tagliamonte <paultag@gmail.com> wrote: > Hello SELinux folks, Hello fellow Paul. > I'm running a test system using MCS and just starting to get to the > point where I'm interested in enabling NetLabel + CIPSO to pass along > context on a LAN. As a first step, I was able to get it working off > `localhost` before adding in CIPSO or other boxen. > > I'm able to run in enforcing mode (amazing!) and get the peer context > (even more amazing!) -- which I can use to calculate the effective > "connection context" for logical filtering on common categories. > That's really great! I'll admit to being a bit biased, but yeah, it is pretty cool ;) However, there are a few words of caution I should share. First, you will want to make sure that you protect your IPv4 header if you are sending CIPSO traffic across an untrusted network. Second, you need to make sure that any of your network hops/middle-boxes don't strip IPv4 options; if they do, you'll lose your CIPSO labels. The good news is that in both cases encapsulating your network traffic in a VPN or some other form of protected tunnel should solve both problems. If you use IPv6, CALIPSO has similar concerns, although due to the nature of CALIPSO and IPv6 the middle-box problem shouldn't really be an issue. There is also labeled IPsec, but it is SELinux only and if you don't carefully synchronize your policies across nodes you can get into some odd/dangerous situations. People really like labeled IPsec because you can transmit the full SELinux label over the wire and not just the MLS/MCS information, but it's a bad design IMHO; you're better off with CIPSO/CALIPS+IPsec if you can get by with just the MLS/MCS information. > I'm a bit confused with some of the enforcement on this, though. When > I run my server (with a user and binary at the level of `s0:c1`), > connecting to localhost via a user at `s0` results in a connection > getting established. > > While I understand this isn't the same as MLS / sensitivity level, I'm > a bit surprised that it didn't refuse to connect to the privileged > resource. Certainly I can't cat a file from a user at `s0` that's at > `s0:c1`, or likely (I haven't tried, but it stands to reason) a UNIX > Socket with `c1` -- so the TCP connection going through was a bit > surprising. I can see in the peer context that the user is at `s0` > (without `c1`), so it'd be possible to filter this software-side, but > it'd also be a bit more of a mental relief if only processes with the > `c1` category could connect. > > Is there any documentation on how to set that particular type of enforcement? You didn't mention what distro and/or policy you are using (other than MCS), but my guess is you are running into a situation where the SELinux policy constraints are not set as expected. I know in the past the MCS labeled networking constraints were a bit lax, even outright missing at one point, so that would be a good place to start. However, since most people are a bit lost when it comes to policy constraints, let me introduce you to The SELinux Notebook: * https://github.com/SELinuxProject/selinux-notebook ... it is an *amazing* freely available resource, that I would encourage you to take a look at if you haven't already. It's source material is in GitHub friendly Markdown, and you can render it into HTML and PDF if you like using the provided Makefile. The Notebook has a section on policy constraints where it provides some expalantion of the "mlscontrain" statement, which I believe is where your problem lies: * https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md * https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md#mlsconstrain ... from there it is a matter of inspecting your policy to see what it specifies for the MLS/MCS network controls - good luck! -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: MCS NetLabel 2021-04-18 21:18 ` Paul Moore @ 2021-04-18 21:56 ` Paul R. Tagliamonte 2021-04-19 1:44 ` Paul Moore 0 siblings, 1 reply; 4+ messages in thread From: Paul R. Tagliamonte @ 2021-04-18 21:56 UTC (permalink / raw) To: Paul Moore; +Cc: SElinux list [ Resending -- my email was HTML and got rejected. Sorry for two emails, Paul :) ] On Sun, Apr 18, 2021 at 5:19 PM Paul Moore <paul@paul-moore.com> wrote: > > On Sun, Apr 18, 2021 at 4:02 PM Paul R. Tagliamonte <paultag@gmail.com> wrote: > > Hello SELinux folks, > > Hello fellow Paul. Ah! Paul! A true pleasure -- and thanks again for all your documentation! I wouldn't be nearly as far as I am without you. I hope you know how many of us out here are very grateful for your tireless work, Paul! > I'll admit to being a bit biased, but yeah, it is pretty cool ;) > > However, there are a few words of caution I should share. First, you > will want to make sure that you protect your IPv4 header if you are > sending CIPSO traffic across an untrusted network. Second, you need > to make sure that any of your network hops/middle-boxes don't strip > IPv4 options; if they do, you'll lose your CIPSO labels. The good > news is that in both cases encapsulating your network traffic in a VPN > or some other form of protected tunnel should solve both problems. If > you use IPv6, CALIPSO has similar concerns, although due to the nature > of CALIPSO and IPv6 the middle-box problem shouldn't really be an > issue. Understood on all counts, thank you very much! > There is also labeled IPsec, but it is SELinux only and if you don't > carefully synchronize your policies across nodes you can get into some > odd/dangerous situations. People really like labeled IPsec because > you can transmit the full SELinux label over the wire and not just the > MLS/MCS information, but it's a bad design IMHO; you're better off > with CIPSO/CALIPS+IPsec if you can get by with just the MLS/MCS > information. Got it. That's super helpful, thanks. > You didn't mention what distro and/or policy you are using (other than > MCS), but my guess is you are running into a situation where the > SELinux policy constraints are not set as expected. I know in the > past the MCS labeled networking constraints were a bit lax, even > outright missing at one point, so that would be a good place to start. I'm running Debian sid -- which I am fully eyes-open about how stale and/or actively busted our policy is. I don't think too many people have MCS configured on their systems, so it's not going to be a huge shock to me when this is part of the root cause here. I have a pile of stuff I'm loading in even to get stuff to where I'm at now, and I think long-term I'll likely try to start agitating on ways to get Debian's policy a bit more up to date. That's a windmill for another day, though, I think. Our SELinux maintainers work very hard and I don't want to add work for them without being able to pitch in. I've uploaded netlabel-tools to Debian[1] back in October, and I've been playing a bit with netlabel on my home network (both to get better at SELinux generally an CIPSO/CALIPSO/NetLabel specifically) so I can effectively triage/debug issues in Debian. I know basically no one is in the same boat as me, and I'm OK with that :) > However, since most people are a bit lost when it comes to policy > constraints, let me introduce you to The SELinux Notebook: > > * https://github.com/SELinuxProject/selinux-notebook > > ... it is an *amazing* freely available resource, that I would > encourage you to take a look at if you haven't already. It's source > material is in GitHub friendly Markdown, and you can render it into > HTML and PDF if you like using the provided Makefile. The Notebook > has a section on policy constraints where it provides some expalantion > of the "mlscontrain" statement, which I believe is where your problem > lies: Amazing. Lovely. Thank you! I will be sure to go through this and work through issues as I find them. Thanks for the pointer, I hadn't found this yet! > * https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md > * https://github.com/SELinuxProject/selinux-notebook/blob/main/src/constraint_statements.md#mlsconstrain > > ... from there it is a matter of inspecting your policy to see what it > specifies for the MLS/MCS network controls - good luck! Perfect. Thanks, Paul! [Mirror Universe] Paul > -- > paul moore > www.paul-moore.com [1]: https://tracker.debian.org/pkg/netlabel-tools -- :wq ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: MCS NetLabel 2021-04-18 21:56 ` Paul R. Tagliamonte @ 2021-04-19 1:44 ` Paul Moore 0 siblings, 0 replies; 4+ messages in thread From: Paul Moore @ 2021-04-19 1:44 UTC (permalink / raw) To: Paul R. Tagliamonte; +Cc: SElinux list On Sun, Apr 18, 2021 at 5:56 PM Paul R. Tagliamonte <paultag@gmail.com> wrote: > On Sun, Apr 18, 2021 at 5:19 PM Paul Moore <paul@paul-moore.com> wrote: > > > > On Sun, Apr 18, 2021 at 4:02 PM Paul R. Tagliamonte <paultag@gmail.com> wrote: > > > Hello SELinux folks, > > > > Hello fellow Paul. > > Ah! Paul! A true pleasure -- and thanks again for all your documentation! I > wouldn't be nearly as far as I am without you. I hope you know how many of > us out here are very grateful for your tireless work, Paul! Thank you, that's very nice of you to say, but Richard Haines and the other Notebook contributors are the ones who deserve the credit (check the git log, not everyone adds their name to the copyright page!). Richard was kind enough to put together The SELinux Notebook in the first place and offer it under a public license; my role thus far has simply been to post it to GitHub on behalf of Richard, do some minor cleanup, tweak the HTML/PDF CSS a bit, and merge patches as they hit the list. The SELinux project is very fortunate to have a good sized community with a number of contributors, and I'm very happy to say we've made some big improvements to documentation and testing over the past few years. > > You didn't mention what distro and/or policy you are using (other than > > MCS), but my guess is you are running into a situation where the > > SELinux policy constraints are not set as expected. I know in the > > past the MCS labeled networking constraints were a bit lax, even > > outright missing at one point, so that would be a good place to start. > > I'm running Debian sid -- which I am fully eyes-open about how stale > and/or actively busted our policy is. I don't think too many people have > MCS configured on their systems, so it's not going to be a huge shock > to me when this is part of the root cause here. > > I have a pile of stuff I'm loading in even to get stuff to where I'm at > now, and I think long-term I'll likely try to start agitating on ways to > get Debian's policy a bit more up to date. That's a windmill for another > day, though, I think. Our SELinux maintainers work very hard and > I don't want to add work for them without being able to pitch in. I've long wanted to start doing regular testing of the bleeding edge kernel bits (the "kernel-secnext" testing) on Debian as well as Fedora. While Fedora has been an excellent "home" for SELinux development, I think it is important that we strive to bring that same SELinux experience to other distros too. Debian seemed to be an obvious next choice to me, and while the kernel-secnext testing is only a small part of that I'm hopeful it will have a positive impact on the effort ... when I get some time to do that of course :/ > I've uploaded netlabel-tools to Debian[1] back in October, and I've been > playing a bit with netlabel on my home network (both to get better > at SELinux generally an CIPSO/CALIPSO/NetLabel specifically) > so I can effectively triage/debug issues in Debian. > > I know basically no one is in the same boat as me, and I'm OK with that :) We're all in different boats, and I think that's a good thing :) > > However, since most people are a bit lost when it comes to policy > > constraints, let me introduce you to The SELinux Notebook: > > > > * https://github.com/SELinuxProject/selinux-notebook > > > > ... it is an *amazing* freely available resource, that I would > > encourage you to take a look at if you haven't already. It's source > > material is in GitHub friendly Markdown, and you can render it into > > HTML and PDF if you like using the provided Makefile. The Notebook > > has a section on policy constraints where it provides some expalantion > > of the "mlscontrain" statement, which I believe is where your problem > > lies: > > Amazing. Lovely. Thank you! I will be sure to go through this and work > through issues as I find them. Thanks for the pointer, I hadn't found this > yet! If you find any problems, or have some text that you think would be a nice addition, patches are always welcome :) -- paul moore www.paul-moore.com ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-04-19 1:44 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-18 20:01 MCS NetLabel Paul R. Tagliamonte 2021-04-18 21:18 ` Paul Moore 2021-04-18 21:56 ` Paul R. Tagliamonte 2021-04-19 1:44 ` Paul Moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.