Re: strange pam selinux issue

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

 



On Wed, Mar 04, 2020 at 03:36:50PM +0100, Dominick Grift wrote:
> On Wed, Mar 04, 2020 at 09:22:42AM -0500, Stephen Smalley wrote:
> > On Wed, Mar 4, 2020 at 2:44 AM Dominick Grift
> > <dominick.grift@xxxxxxxxxxx> wrote:
> > >
> > > On Wed, Mar 04, 2020 at 08:29:40AM +0100, Dominick Grift wrote:
> > > > The easiest way to explain this is as follows.
> > > >
> > > > Consider this scenario:
> > > >
> > > > # seinfo -xuwheel.id
> > > >
> > > > Users: 1
> > > >    user wheel.id roles wheel.role level s0 range s0;
> > > >
> > > > # selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
> > > > wheel.id:wheel.role:user.systemd.subj:s0
> > > >
> > > > Now consider this scenario:
> > > >
> > > > # echo '(userrole wheel.id sys.role)' > hack.cil && semodule -i hack.cil
> > > >
> > > > # seinfo -xuwheel.id
> > > >
> > > > Users: 1
> > > >    user wheel.id roles { wheel.role sys.role } level s0 range s0;
> > > >
> > > > Here is the issue:
> > > >
> > > > # selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
> > > > wheel.id:sys.role:sys.isid:s0
> > >
> > > For completeness:
> > >
> > > # cat /etc/selinux/dssp3-mcs/contexts/users/wheel.id
> > > sys.role:login.subj:s0 wheel.role:user.subj:s0
> > > sys.role:ssh.daemon.subj:s0 wheel.role:user.ssh.subj:s0
> > > sys.role:sys.isid:s0 wheel.role:user.systemd.subj:s0
> > 
> > Are you using libselinux with or without the commit to stop using
> > security_compute_user()?
> > If still using security_compute_user(), what does compute_user
> > sys.id:sys.role:sys.isid:s0 wheel.id display?
> > If you don't have compute_user (it is in libselinux/utils but not sure
> > Fedora packages it), you can also just
> > strace -s 4096 -o trace.txt selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
> > and see what it read back from /sys/fs/selinux/user.
> 
> Thanks, it does not even seems to read /etc/selinux/dssp3-mcs/contexts/users/wheel.id...
> I am not if my libselinux has or has not security_compute_user():

Scratch that, the reference to /sys/fs/selinux/user in the trace below implies that security_compute_user() is still there
> 
> # rpm -qa libselinux
> libselinux-3.0-3.fc32.x86_64
> 
> openat(AT_FDCWD, "/sys/fs/selinux/user", O_RDWR|O_CLOEXEC) = 3
> write(3, "sys.id:sys.role:sys.isid:s0 wheel.id", 36) = -1 ERANGE (Numerical result out of range)
> close(3)                                = 0
> openat(AT_FDCWD, "/etc/selinux/dssp3-mcs/contexts/failsafe_context", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=21, ...}) = 0
> read(3, "sys.role:sys.isid:s0\n", 4096) = 21
> close(3)                                = 0
> openat(AT_FDCWD, "/sys/fs/selinux/context", O_RDWR|O_CLOEXEC) = 3
> write(3, "wheel.id:sys.role:sys.isid:s0\0", 30) = 30
> close(3)                                = 0
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
> write(1, "wheel.id:sys.role:sys.isid:s0\n", 30) = 30
> 
> -- 
> gpg --locate-keys dominick.grift@xxxxxxxxxxx
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift



-- 
gpg --locate-keys dominick.grift@xxxxxxxxxxx
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux