| View previous topic :: View next topic |
| Author |
Message |
bpoint
Tux's lil' helper
Joined: 07 Oct 2008
Posts: 93
Location: Japan
|
 Posted: Fri Apr 12, 2024 6:54 am Post subject: fresh install of hardened-selinux-openrc fails to boot |
 |
|
Hi all, long time (15+ year) Gentoo user here, although this is my first time working with an SELinux installation.
After following the usual handbook install, then the SELinux Installation guide (most of which I simply confirmed was already completed as I began with a hardened/selinux stage3 tarball), and relabeling the entire filesystem, I have a working and bootable install as long as the policy is set to *permissive*.
Logging into the console as root, then switching the policy to enforcing mode pretty much shows something is definitely not working right:
| Code: | cheddar ~ # id -Z
system_u:system_r:local_login_t
cheddar ~ # setenforce enforcing
cheddar ~ # id -Z
-bash: child setpgid (30569 to 30569): Permission denied
-bash: /usr/bin/id: Permission denied
|
Attempting to boot with enforcing mode enabled results in OpenRC failing to be able to mount /proc and /run, and it simply gives up from there:
| Code: | OpenRC 0.54 is starting up Gentoo Linux (x86_64)
* Mounting /proc ...
[ 1.775012] audit: type=1400 audit(1712876223.626:8): avc: denied { read } for pid=276 comm="init.sh" name="linux" dev="nvme0n1p3" ino=13772272 scontext=system_u:system_r:init_t tcontext=system_u:object_r:usr_t tclass=
[ 1.775962] audit: type=1400 audit(1712876233.627:9): avc: denied { getattr } for pid=276 comm="init.sh" path="/usr/bin/mount" dev="nvme0n1p3" ino=288673 scontext=system_u:system_r:init_t tcontext=system_u:object_r:mount_t
[ 1.776408] audit: type=1400 audit(1712876233.627:10): avc: denied { getattr } for pid=276 comm="init.sh" path="/usr/bin/mount" dev="nvme0n1p3" ino=288673 scontext=system_u:system_r:init_t tcontext=system_u:object_r:mount_t
/lib/rc/sh/init.sh: line 49: mount: command not found
* getmntinfo: Permission denied
* Mounting /run ...
/lib/rc/sh/init.sh: line 76: mount: command not found
* Unable to mount tmpfs on /run.
* Can't continue.
|
Looking around on the forums for anything similar to this issue turned up this post about how this might be related to relabeling... or rather, performing a manual relabel like I did (as instructed by the guide) ends up breaking things. Indeed, my openrc binary is labeled with bin_t, which sounds like it is the incorrect type, but I'm honestly not sure what it should be.
| Code: | cheddar ~ # ls -lZ /bin/openrc /sbin/openrc /usr/bin/openrc /usr/sbin/openrc
-rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /bin/openrc
-rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /sbin/openrc
-rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /usr/bin/openrc
-rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /usr/sbin/openrc
|
It's entirely likely I've missed or skipped over something, so I'm open to any suggestions on things to try at this point. |
|
| Back to top |
|
 |
bpoint
Tux's lil' helper
Joined: 07 Oct 2008
Posts: 93
Location: Japan
|
| Posted: Fri Apr 12, 2024 11:39 am Post subject: |
|
|
Nothing like a crash course in order to learn how SELinux works! 
Fixing the files that are incorrectly tagged as bin_t with the following commands, I've been able to get the boot process to a login prompt, but all logins fail (root/user, console/ssh) so it's not fully working yet:
| Code: | cheddar ~ # chcon -v system_u:object_r:initrc_exec_t /lib/rc/sh/init.sh
changing security context of '/lib/rc/sh/init.sh'
cheddar ~ # chcon -v system_u:object_r:rc_exec_t /usr/sbin/openrc
changing security context of '/usr/sbin/openrc'
cheddar ~ # chcon -v system_u:object_r:init_exec_t /usr/sbin/openrc-init
changing security context of '/usr/sbin/openrc-init'
cheddar ~ # chcon -v system_u:object_r:init_exec_t /usr/sbin/openrc-shutdown
changing security context of '/usr/sbin/openrc-shutdown'
|
What I still don't fully understand is why restorecon won't properly set the correct policy in the first place. Everything points to that the policy for /usr/sbin/openrc should be rc_exec_t, but it's always restored as bin_t...
| Code: | cheddar ~ # ls -lZ /usr/sbin/openrc
-rwxr-xr-x. 1 root root system_u:object_r:rc_exec_t 55416 Apr 11 21:36 /usr/sbin/openrc
cheddar ~ # semanage fcontext -l | grep "/usr/sbin/openrc "
/usr/sbin/openrc regular file system_u:object_r:rc_exec_t
cheddar ~ # getfattr -n security.selinux /usr/sbin/openrc
getfattr: Removing leading '/' from absolute path names
# file: usr/sbin/openrc
security.selinux="system_u:object_r:rc_exec_t"
cheddar ~ # restorecon -v /usr/sbin/openrc
Relabeled /usr/bin/openrc from system_u:object_r:rc_exec_t to system_u:object_r:bin_t
|
|
|
| Back to top |
|
|
nicop
n00b
Joined: 10 Apr 2014
Posts: 41
|
| Posted: Fri Apr 12, 2024 12:08 pm Post subject: |
|
|
| bpoint wrote: |
cheddar ~ # ls -lZ /usr/sbin/openrc
-rwxr-xr-x. 1 root root system_u:object_r:rc_exec_t 55416 Apr 11 21:36 /usr/sbin/openrc
cheddar ~ # semanage fcontext -l | grep "/usr/sbin/openrc "
/usr/sbin/openrc regular file system_u:object_r:rc_exec_t
cheddar ~ # getfattr -n security.selinux /usr/sbin/openrc
getfattr: Removing leading '/' from absolute path names
# file: usr/sbin/openrc
security.selinux="system_u:object_r:rc_exec_t"
cheddar ~ # restorecon -v /usr/sbin/openrc
Relabeled /usr/bin/openrc from system_u:object_r:rc_exec_t to system_u:object_r:bin_t
|
sbin != bin
Create a policy for /usr/bin/openrc
EDIT :
the command chcon is not permanent.
use instead : | Code: | | semanage fcontext -a -t rc_exec_t "/usr/bin/openrc" |
|
|
| Back to top |
|
|
bpoint
Tux's lil' helper
Joined: 07 Oct 2008
Posts: 93
Location: Japan
|
| Posted: Fri Apr 12, 2024 1:07 pm Post subject: |
|
|
I'm aware of that. But this is a fresh install, and the only SELinux policy entry for openrc is listed as /usr/sbin:
| Code: | cheddar ~ # semanage fcontext -l | grep "openrc "
/usr/sbin/openrc regular file system_u:object_r:rc_exec_t
cheddar ~ #
|
Also since openrc is hardlinked to four different locations, changing the policy for one of them implicitly also changes it for all of them anyway:
| Code: | cheddar ~ # ls -liZ /bin/openrc /sbin/openrc /usr/bin/openrc /usr/sbin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /bin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /sbin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /usr/bin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:bin_t 55416 Apr 11 21:36 /usr/sbin/openrc
cheddar ~ # chcon -v system_u:object_r:rc_exec_t /usr/sbin/openrc
changing security context of '/usr/sbin/openrc'
cheddar ~ # ls -liZ /bin/openrc /sbin/openrc /usr/bin/openrc /usr/sbin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:rc_exec_t 55416 Apr 11 21:36 /bin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:rc_exec_t 55416 Apr 11 21:36 /sbin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:rc_exec_t 55416 Apr 11 21:36 /usr/bin/openrc
271758 -rwxr-xr-x. 1 root root system_u:object_r:rc_exec_t 55416 Apr 11 21:36 /usr/sbin/openrc
|
| nicop wrote: | Create a policy for /usr/bin/openrc
|
Thanks, I did notice that was the suggestion from the PR you linked to in the other thread. I do plan to go that route in the end once I figure out everything that needs fixing.
| nicop wrote: | EDIT :
the command chcon is not permanent.
use instead : | Code: | | semanage fcontext -a -t rc_exec_t "/usr/bin/openrc" |
|
Right now I'm only interested in incrementally doing temporary changes to figure out what is actually broken. Plus, chcon is "permanent" enough to last across reboots for testing. |
|
| Back to top |
|
|
nicop
n00b
Joined: 10 Apr 2014
Posts: 41
|
| Posted: Fri Apr 12, 2024 1:38 pm Post subject: |
|
|
It's ok for hardlinks. But how to be sure of the label applying for /usr/sbin/openrc and /usr/bin/openrc ? Policy for /usr/bin/openrc or /usr/sbin/openrc ? (https://wiki.gentoo.org/wiki/SELinux/FAQ#During_rlpkg_I_get_.27conflicting_specifications_for_..._and_....2C_using_....27) :
| wiki.gentoo.org wrote: | | Both files are used for the same purpose; in this case, it might be better to label the file which would not be labeled correctly (say a binary somewhere in a /usr/lib64/ location) using semanage (semanage fcontext -a -t correct_domain_t /usr/lib64/path/to/file) |
| bpoint wrote: | | Right now I'm only interested in incrementally doing temporary changes to figure out what is actually broken. Plus, chcon is "permanent" enough to last across reboots for testing. |
chcon is permanent enough for a reboot, yes, but not enough for relabeling with restorecon. So you can't test your policy with restorecon for a file previously labeled with chcon. |
|
| Back to top |
|
|
bpoint
Tux's lil' helper
Joined: 07 Oct 2008
Posts: 93
Location: Japan
|
| Posted: Fri Apr 12, 2024 3:38 pm Post subject: |
|
|
Aaaaah, that makes sense! That also explains why this shows the paths with /usr/bin, and where the "bin_t" context is coming from:
| Code: | cheddar ~ # restorecon -Rvn /
Would relabel /usr/bin/openrc-init from system_u:object_r:init_exec_t to system_u:object_r:bin_t
Would relabel /usr/bin/openrc from system_u:object_r:rc_exec_t to system_u:object_r:bin_t
Would relabel /usr/bin/openrc-shutdown from system_u:object_r:init_exec_t to system_u:object_r:bin_t
|
I've went ahead and applied rules for /usr/bin/openrc{,-init,-shutdown} since those appear to be correct, but I'm still unable to actually login when enforcing is enabled:
| Code: | * Remounting root filesystem read/write ...
* Remounting filesystems ...
* Updating /etc/mtab ...
* Creating mtab symbolic link
ln: failed to create symbolic link '/etc/mtab': Permission denied
* Activating swap devices ...
* Mouting local filesystems ...
* Configuring kernel parameters ...
mount: /tmp/tmp.AU33GlmQoN: bind / failed.
dmesg(1) may have more information after failed mount system call.
umount: /tmp/tmp.AU33GlmQoN: not mounted.
* Could not clean up underlying /run on /
[...]
This is cheddar (Linux x86_64 6.6.21-gentoo) 23:46:23
cheddar login: root
Password:
Login incorrect
cheddar login: root
Password:
Login incorrect |
There are a still a couple of errors during startup, but I haven't been able to pinpoint the root cause yet. I also really have no idea why I can't login either, as the audit.log doesn't really show anything useful at all... |
|
| Back to top |
|
|
nicop
n00b
Joined: 10 Apr 2014
Posts: 41
|
|
| Back to top |
|
|
bpoint
Tux's lil' helper
Joined: 07 Oct 2008
Posts: 93
Location: Japan
|
| Posted: Sat Apr 13, 2024 7:11 am Post subject: |
|
|
Finally, some progress!
As I said above, for some reason, I'm unable to login as anyone when SELinux enforcing is enabled, but it seems this is limited to password authentication only. After copying over my public key and using ssh with key-based authentication, I can successfully login with enforcing enabled:
| Code: | Michaels-Mac-Studio:~ $ ssh falken@192.xxx..
Last login: Sat Apr 13 15:02:16 2024 from 192.xxx..
falken@cheddar ~ $ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: strict
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: disabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33 |
Whatever is blocking password authentication is also affecting sudo though, as I unfortunately can't switch to root yet...
| Code: | falken@cheddar ~ $ sudo su
Password:
Sorry, try again.
Password:
Sorry, try again.
Password:
sudo: 3 incorrect password attempts
falken@cheddar ~ $
|
Thanks! audit2allow looks like it'll be helpful. I'll give it a shot.
| nicop wrote: | Do you have many hours/days ?
|
Yes I never stop learning! |
|
| Back to top |
|
|
|
Installing Gentoo
