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.overr...@gmail.com>
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
