Re: SELinux status report and call to action
On 1/13/21 5:42 PM, David Lang wrote: > OpenWRT uses different commands than other distros for manipulating > configs, so those different programs are going to need to be given > appropriate permissions. UCI should already be addressed barring any loose ends (LuCI coverage is still rough though) > > Who is going to do that work? Who is going to field all the issues that > will come up because the permissions are not correct for some user's > setup (and how many people will be able to figure out that SELinux > caused the problem as opposed to "OpenWRT doesn't work") UCI should be covered and the README in my repository clearly states: "Contributing Thank you for considering contributing! Please send patches with git-send-email to dominick.gr...@defensec.nl and sign your work." I suppose I should clarify that bug reports can also be directed to the above email address. If you have better ideas then please let us know. I guess people can also report github issues for the "selinux-policy" packages. I am monitoring github as well so if something shows up i will probably be on top of it. > > If it's just enabled with a permissive ruleset, what's the advantage of > the additional overhead (both from the permission checking, and the > logging of the results)? It is currently *not* enabled with a permissive ruleset. But i think that, for now, it might be a good idea to leave SELinux in permisisve mode. There are two reasons for this: 1. SELinux will be in detection only mode rather than prevention mode so that stuff just works but events that would have been prevented if SELinux were enforcing are still logged. 2. This will make it so that SELinux doesnt actively block (for now) so that we can identify any permissions that are needed (because SELinux will print any events that it would have blocked and those events can be feed back to me so that i can append the needed rules) Then after a while we can switch to enforcing mode. Ofcourse any of you OpenWrt devs can just modify the package to make SELinux permissive yourself easily (its easy, but if making it permissive for now by default helps people get to try it then we might want to default to permisisve) > > Yes other distros had to go through this same pain, but that doesn't > mean that the pain isn't there for OpenWRT as well. The difference is that we had a chance to learn from their "mistakes". I went to great lengths to make it proof. Also OpenWrt is not like other distro's. It is *much* simpler. LuCI poses a challenge though. There are various components involved and to address it in a meaningful way is rather intrusive. (however one can build the policy without the LuCI aspects which simplifies things a great deal. LuCI is also very modular, and al these modules have to be addressed. Otherwise you end up with LuCI where various spokes do not show up or if they show up the will not be allowed to function. I addressed most of the basic LuCI apects. So the basics work but again there are many optional modules that have to be supported and then tested. > > David Lang > > On Wed, 13 Jan 2021, Dac Override wrote: > >> Date: Wed, 13 Jan 2021 17:34:56 +0100 >> From: Dac Override >> To: openwrt-devel@lists.openwrt.org >> Subject: Re: Re: SELinux status report and call to action >> >> Hello Alberto, >> >> Thanks for you input. I agree that leveraging SELinux is, like for >> example leveraging Linux netfilter, not trivial. >> SELinux is however well documenting and with the exception of OpenWrt >> specifics it might not be productive to yet again document aspects >> that are already published elsewhere. >> >> I have created a document that explains how to build and edit the >> OpenWrt policy and I have also enclosed a link to the policy language >> used to write the OpenWrt policy: >> >> https://git.defensec.nl/?p=selinux-policy.git;a=summary >> >> 1. The CIL used to write OpenWrt policy: >> https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md >> >> 2. OpenWrt policy customization and testing: >> https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md >> >> Generally one should not have to interact with SELinux in OpenWrt but >> there are some exceptions >> >> 1. Some commands might be "targeted" by default and *if* a command >> cannot operate properly because it is targeted then you can manually >> run the command "unconfined": For example: you want to use `iw` but >> SELinux blocks it, then you can run iw from a shell with `runcon -t >> sys.subj -- iw` to by pass the SELinux restrictions. >> >> 2. Some commands might *not* be targeted by default and *if* you want
Re: Re: SELinux status report and call to action
OpenWRT uses different commands than other distros for manipulating configs, so those different programs are going to need to be given appropriate permissions. Who is going to do that work? Who is going to field all the issues that will come up because the permissions are not correct for some user's setup (and how many people will be able to figure out that SELinux caused the problem as opposed to "OpenWRT doesn't work") If it's just enabled with a permissive ruleset, what's the advantage of the additional overhead (both from the permission checking, and the logging of the results)? Yes other distros had to go through this same pain, but that doesn't mean that the pain isn't there for OpenWRT as well. David Lang On Wed, 13 Jan 2021, Dac Override wrote: Date: Wed, 13 Jan 2021 17:34:56 +0100 From: Dac Override To: openwrt-devel@lists.openwrt.org Subject: Re: Re: SELinux status report and call to action Hello Alberto, Thanks for you input. I agree that leveraging SELinux is, like for example leveraging Linux netfilter, not trivial. SELinux is however well documenting and with the exception of OpenWrt specifics it might not be productive to yet again document aspects that are already published elsewhere. I have created a document that explains how to build and edit the OpenWrt policy and I have also enclosed a link to the policy language used to write the OpenWrt policy: https://git.defensec.nl/?p=selinux-policy.git;a=summary 1. The CIL used to write OpenWrt policy: https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md 2. OpenWrt policy customization and testing: https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md Generally one should not have to interact with SELinux in OpenWrt but there are some exceptions 1. Some commands might be "targeted" by default and *if* a command cannot operate properly because it is targeted then you can manually run the command "unconfined": For example: you want to use `iw` but SELinux blocks it, then you can run iw from a shell with `runcon -t sys.subj -- iw` to by pass the SELinux restrictions. 2. Some commands might *not* be targeted by default and *if* you want to run that command with "basic" set of restrictions then you can run the command in a "SELinux sandbox". For example you want to run `bmon` with restricted permissions but SELinux does not target it by default then you can run bmon from a shell with `runcon -t sandbox.subj -- bmon` or `runcon -t sandbox.net,subj -- bmon` (you can also execute a restricted shell or tmux session this way (runcon -t sandbox.net.subj -- sh or runcon -t sandbox.net.subj -- tmux) 3. If a file for some reason ends up with a bad label (SELinux associates labels with inodes using the security.selinux security extended attribute) then you can use restorecon command. I have many video's on youtube with casual demonstrations on how to address various SELinux/OpenWrt issues and other case studies: For example: chronyd recently (in november last year) enhanced configuration and packaging, and so I had to adjust the policy so that the changes work. I documented the whole process here: https://www.youtube.com/watch?v=xC-YrlCR7iU Here is a demonstration of the SELinux openwrt sandbox functionality: https://www.youtube.com/watch?v=Ic_k9qknh_Q Filesystem management with SELinux and OpenWrt (zram example with f2fs): https://www.youtube.com/watch?v=R1wyv_poN4U There are various other videos on my channel with casual demo's and ramblings: Here is approx. 3 hours of SELinux with OpenWrt ramble touching on various topic: https://www.youtube.com/watch?v=Q4_SWTAcQSY Maybe we should create a Wiki page on the OpenWrt website where we can bundle these resources. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: SELinux status report and call to action
Hello Alberto, Thanks for you input. I agree that leveraging SELinux is, like for example leveraging Linux netfilter, not trivial. SELinux is however well documenting and with the exception of OpenWrt specifics it might not be productive to yet again document aspects that are already published elsewhere. I have created a document that explains how to build and edit the OpenWrt policy and I have also enclosed a link to the policy language used to write the OpenWrt policy: https://git.defensec.nl/?p=selinux-policy.git;a=summary 1. The CIL used to write OpenWrt policy: https://github.com/SELinuxProject/selinux/blob/master/secilc/docs/README.md 2. OpenWrt policy customization and testing: https://github.com/doverride/openwrt-selinux-policy/blob/master/README.md Generally one should not have to interact with SELinux in OpenWrt but there are some exceptions 1. Some commands might be "targeted" by default and *if* a command cannot operate properly because it is targeted then you can manually run the command "unconfined": For example: you want to use `iw` but SELinux blocks it, then you can run iw from a shell with `runcon -t sys.subj -- iw` to by pass the SELinux restrictions. 2. Some commands might *not* be targeted by default and *if* you want to run that command with "basic" set of restrictions then you can run the command in a "SELinux sandbox". For example you want to run `bmon` with restricted permissions but SELinux does not target it by default then you can run bmon from a shell with `runcon -t sandbox.subj -- bmon` or `runcon -t sandbox.net,subj -- bmon` (you can also execute a restricted shell or tmux session this way (runcon -t sandbox.net.subj -- sh or runcon -t sandbox.net.subj -- tmux) 3. If a file for some reason ends up with a bad label (SELinux associates labels with inodes using the security.selinux security extended attribute) then you can use restorecon command. I have many video's on youtube with casual demonstrations on how to address various SELinux/OpenWrt issues and other case studies: For example: chronyd recently (in november last year) enhanced configuration and packaging, and so I had to adjust the policy so that the changes work. I documented the whole process here: https://www.youtube.com/watch?v=xC-YrlCR7iU Here is a demonstration of the SELinux openwrt sandbox functionality: https://www.youtube.com/watch?v=Ic_k9qknh_Q Filesystem management with SELinux and OpenWrt (zram example with f2fs): https://www.youtube.com/watch?v=R1wyv_poN4U There are various other videos on my channel with casual demo's and ramblings: Here is approx. 3 hours of SELinux with OpenWrt ramble touching on various topic: https://www.youtube.com/watch?v=Q4_SWTAcQSY Maybe we should create a Wiki page on the OpenWrt website where we can bundle these resources. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SELinux status report and call to action
On 12/01/21 18:27, Dominick Grift wrote: - My question to the reader is: why haven't you enabled SELinux yet on your test builds at least? Or maybe you have but you havent given any feedback. Why is that? Thanks, Lack of documentation. Selinux is not an easy topic even on a normal Linux distro, and there is little if any info on how to use it (or why use it) in OpenWrt. I think a necessary first step for adoption is writing some docs about what it is, and how to use it in the wiki/site openwrt.org Since I know very little about it, I can't do that. But you said you gave a talk about this topic in a large conference, maybe you can write some documentation? -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: SELinux status report and call to action
On 1/12/21 6:27 PM, Dominick Grift wrote: > > Community, > > Optional SELinux support has been added to OpenWrt for a while now and I > gave a talk about the status at "Battle of the meshes 13th edition". > > There was a comment mentioning that there was an impression that > "rolling out SELinux on OpenWrt" would still require lots of work and > that there are still lots of "loose ends". I failed to ask the person > what work and what loose ends he still see's. > > Regardless in the few months that have passed I have had give or take three > times feedback on SELinux in OpenWrt: > > 1. dangole tests bootstrap every once in a while and if needed he > provides me with information and contributions needed to get and keep > that to work on atleast devices and configurations he is using. > > 2. I had one person e-mailing me mentioning that, i guess, WPA > enterprise, does not work and that wpa_supplicant needs to be able to > connect to a radius server for this (i addressed that issue to the > best of my ability but havent heared from the person since and I am not > sure whether that means that its is fixed or that the person hasnt > tested it since the fixed trickled down) > > 3. jow gave some casual feedback on running services on alternate > network ports and i addressed this issue as well although the fix for > that might not have trickled down yet. > > I was hoping for a little more exposure and feedback than this. The way > i see it, it should not be much of an extra burden for OpenWrt devs to > build their systems with SELinux support and to report any obvious > issues back so that the effort can evolve instead of face early death. > > My question to the reader is: why haven't you enabled SELinux yet on > your test builds at least? Or maybe you have but you havent given any > feedback. Why is that? > > Is it too much of a burden? If that is the case we could for now > consider shipping a "permissive" policy so that SELinux will never > be in your way if that helps. > > Can you please consider just enabling SELinux on your tests? If there > are any observations and SELinux related messages in the logs then > please report those to me via email or IRC? > > If you have objections then please let me know what those objections are > so that I can identify whether those objections can be addressed. > > I did not, and do not expect that SELinux adoption would be popular but > for developers that are very familiar with OpenWrt I do not see much of > a reason not to enable it on test builds/systems either. Your feedback > is valuable and is important to help improve the experience. > > SELinux on OpenWrt works great for me and to be honest that is my first > priority but with a little more involvement and interest from others > there is much more room for improvement. > > If you just build your systems with SELinux enabled and then provide > feedback if there is something to report then that would be > appreciated. If something is stopping you and if there is something i > can do to make it easier then please let it be known. > > Thanks, > I received some feedback off-list and there was some chatter on IRC. This reminds me that I should mention that LuCI integration is known to have a lot of rough edges (although, with the exception of sysupgrade and package management, most of the *LuCI-basics* should work). To be honest I did not expect it that aside from LuCI developers, users of this list would be using LuCI on development snapshots. Nevertheless, be aware that LuCI has known rough edges and that I see LuCI as a separate optional layer. I am not trying to justify the issues there (and I do also appreciate any LuCI feedback), but LuCI needs a lot more work. Please do not let that stand in the way of testing the remainder of OpenWrt. Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
