SELinux status report and call to action

David Lang david at lang.hm
Wed Jan 13 11:42:51 EST 2021


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 <dac.override at gmail.com>
> To: openwrt-devel at 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 at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>



More information about the openwrt-devel mailing list