lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] ZOMG selinux


From: Vadim Zeitlin
Subject: Re: [lmi] ZOMG selinux
Date: Sun, 31 Oct 2021 16:46:48 +0100

On Sun, 31 Oct 2021 00:21:02 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> /home/GREG[0]$sudo su -
GC> Last login: [REDACTED]
GC> /root[0]#ls -ldZ /srv
GC> drwxr-xr-x. root root system_u:object_r:var_t:s0       /srv
GC> /root[0]#ls -ldZ /srv/chroot
GC> drwxr-xr-x. root root system_u:object_r:var_t:s0       /srv/chroot
GC> /root[0]#ls -ldZ /srv/chroot/lmi_b*
GC> drwxrwx---. root root unconfined_u:object_r:var_t:s0   
/srv/chroot/lmi_bookworm_4
GC> drwxrwxr-x. root root unconfined_u:object_r:var_t:s0   
/srv/chroot/lmi_bullseye_3
GC> 
GC> The older "bullseye_3" chroot works; the "bookworm_4" one doesn't.
GC> I can remove that '---' vs. 'r-x' difference. Both normal users are
GC> members of an 'lmi' group, but neither belongs to the 'root' group,
GC> so we'd only have '---' permissions to the chroot's '/'.

 Yes, this definitely explains why you can't access anything under this
directory.

GC> /root[1]#id -Z
GC> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
GC> /root[0]#exit
GC> /home/GREG[0]$id -Z
GC> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

 Thanks, I think we won't need this information now and, in fact, I'm not
even sure if SELinux is enabled for you (what does "getenforce" output?),
but it could be useful in the future. AFAIU these role/type don't prevent
you from doing anything.

GC> Both users are member of the 'lmi' group, and the selinux contexts
GC> are the same, so I should think we'd have 'rwx' access to '/opt/lmi/'
GC> in both chroots.

 While I know very little about SELinux, I do know that it comes after the
classic Unix permissions enforcement. I.e. it will never allow you to
access something that you're forbidden from accessing by the classic file
permissions -- as is the case here. If the normal permissions check fails,
access fails and SELinux isn't involved at all, i.e. it won't even log it
as a failure. It's only if you're allowed to access some object that
SELinux rules are used.

GC> But tomorrow I'll try liberalizing the classic *nix
GC> permissions for the "bookworm" chroot.

 I'm quite confident that this should fix the problem, but please let me
know if it doesn't and if I really need to read/experiment more with
SELinux.

 Thanks,
VZ

Attachment: pgpnwGNeZLE1d.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]