strange pam selinux issue

strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

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


Some semi irrelevant background:

I am designing an improved "targeted" policy. Common targeted policies
are inefficient because they have several "unconfined" domains.
Unconfined domains are expensive because they have a lot of rules associated with them.
They're essentially all the same. Just duplicates.

I decided to have just one unconfined domain: "the system", and everything that is not targeted ends up in the system domain.
So now I want to have a confined login shell with role access to the system a'la: staff_u:staff_r:staff_t -> staff_u:unconfined_r:unconfined_t
pam_selinux seemingly cannot deal with this scenario as shown above. pam_selinux has many other issues. One of them is its concept of
"default_type". There is no such thing as a "default_type" and implying that there is a "default_type" causes issues.

There are other issues related to this as well: the env_params option depends on the "context contains" access vector being present.
It will not work even if you have handle_unknown=allow set.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Stephen Smalley]

On Wed, Mar 4, 2020 at 2:44 AM Dominick Grift
<dominick.grift@defensec.nl> 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.

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2775 bytes --]

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@defensec.nl> 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():

# 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@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]

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@defensec.nl> 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@defensec.nl
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift



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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Stephen Smalley]

On Wed, Mar 4, 2020 at 9:36 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> On Wed, Mar 04, 2020 at 09:22:42AM -0500, Stephen Smalley wrote:
> > 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():
>
> # 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)

This shows that your libselinux is still calling
security_compute_user() from get_ordered_context_list().
In this case, because the source context is allowed to transition to
many other contexts, the result returned via
/sys/fs/selinux/user would exceed the maximum size supported by the
kernel interface (one page of contexts),
and therefore it fails.  Then get_ordered_context_list() falls back to
the failsafe_context.

If you update to libselinux git, you will stop using
security_compute_user() and hence /sys/fs/selinux/user entirely.

Re: strange pam selinux issue

[Stephen Smalley]

On Wed, Mar 4, 2020 at 9:46 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> This shows that your libselinux is still calling
> security_compute_user() from get_ordered_context_list().
> In this case, because the source context is allowed to transition to
> many other contexts, the result returned via
> /sys/fs/selinux/user would exceed the maximum size supported by the
> kernel interface (one page of contexts),
> and therefore it fails.  Then get_ordered_context_list() falls back to
> the failsafe_context.
>
> If you update to libselinux git, you will stop using
> security_compute_user() and hence /sys/fs/selinux/user entirely.

BTW, Fedora ran into this limit some time ago and prune outbound
transitions from init_t and perhaps other "unconfined"
domains to workaround it.  But getting rid of security_compute_user()
and /sys/fs/selinux/user is the better solution.

Re: strange pam selinux issue

[Petr Lautrbach]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Wed, Mar 4, 2020 at 9:36 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>> On Wed, Mar 04, 2020 at 09:22:42AM -0500, Stephen Smalley wrote:
>> > 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():
>>
>> # 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)
>
> This shows that your libselinux is still calling
> security_compute_user() from get_ordered_context_list().
> In this case, because the source context is allowed to transition to
> many other contexts, the result returned via
> /sys/fs/selinux/user would exceed the maximum size supported by the
> kernel interface (one page of contexts),
> and therefore it fails.  Then get_ordered_context_list() falls back to
> the failsafe_context.
>
> If you update to libselinux git, you will stop using
> security_compute_user() and hence /sys/fs/selinux/user entirely.

FYI I've just built libselinux-3.0-4.fc32 [1] and libselinux-3.0-4.fc33
[2] with the security_compute_user() patch applied.

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474378
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474377

-- 
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On Thu, Mar 05, 2020 at 06:33:55PM +0100, Petr Lautrbach wrote:
> 
> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> 
> > On Wed, Mar 4, 2020 at 9:36 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> >>
> >> On Wed, Mar 04, 2020 at 09:22:42AM -0500, Stephen Smalley wrote:
> >> > 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():
> >>
> >> # 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)
> >
> > This shows that your libselinux is still calling
> > security_compute_user() from get_ordered_context_list().
> > In this case, because the source context is allowed to transition to
> > many other contexts, the result returned via
> > /sys/fs/selinux/user would exceed the maximum size supported by the
> > kernel interface (one page of contexts),
> > and therefore it fails.  Then get_ordered_context_list() falls back to
> > the failsafe_context.
> >
> > If you update to libselinux git, you will stop using
> > security_compute_user() and hence /sys/fs/selinux/user entirely.
> 
> FYI I've just built libselinux-3.0-4.fc32 [1] and libselinux-3.0-4.fc33
> [2] with the security_compute_user() patch applied.
> 
> [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474378
> [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474377

Thanks, trying it out
> 
> -- 
> ()  ascii ribbon campaign - against html e-mail 
> /\  www.asciiribbon.org   - against proprietary attachments
> 

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

On Thu, Mar 05, 2020 at 06:39:41PM +0100, Dominick Grift wrote:
> On Thu, Mar 05, 2020 at 06:33:55PM +0100, Petr Lautrbach wrote:
> > 
> > Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> > 
> > > On Wed, Mar 4, 2020 at 9:36 AM Dominick Grift
> > > <dominick.grift@defensec.nl> wrote:
> > >>
> > >> On Wed, Mar 04, 2020 at 09:22:42AM -0500, Stephen Smalley wrote:
> > >> > 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():
> > >>
> > >> # 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)
> > >
> > > This shows that your libselinux is still calling
> > > security_compute_user() from get_ordered_context_list().
> > > In this case, because the source context is allowed to transition to
> > > many other contexts, the result returned via
> > > /sys/fs/selinux/user would exceed the maximum size supported by the
> > > kernel interface (one page of contexts),
> > > and therefore it fails.  Then get_ordered_context_list() falls back to
> > > the failsafe_context.
> > >
> > > If you update to libselinux git, you will stop using
> > > security_compute_user() and hence /sys/fs/selinux/user entirely.
> > 
> > FYI I've just built libselinux-3.0-4.fc32 [1] and libselinux-3.0-4.fc33
> > [2] with the security_compute_user() patch applied.
> > 
> > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474378
> > [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474377
> 
> Thanks, trying it out

[root@myguest ~]# strace -s 4096 -o trace.txt selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
wheel.id:wheel.role:user.systemd.subj:s0
wheel.id:sys.role:sys.isid:s0

So that result looks promising, but when I login I still get wheel.id:sys.role:sys.isid:s0
Is that some compatibility related thing, or does something else need to be rebuilt against this libselinux for it to work?

> > 
> > -- 
> > ()  ascii ribbon campaign - against html e-mail 
> > /\  www.asciiribbon.org   - against proprietary attachments
> > 
> 
> -- 
> gpg --locate-keys dominick.grift@defensec.nl
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift



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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3523 bytes --]

On Thu, Mar 05, 2020 at 06:50:00PM +0100, Dominick Grift wrote:
> On Thu, Mar 05, 2020 at 06:39:41PM +0100, Dominick Grift wrote:
> > On Thu, Mar 05, 2020 at 06:33:55PM +0100, Petr Lautrbach wrote:
> > > 
> > > Stephen Smalley <stephen.smalley.work@gmail.com> writes:
> > > 
> > > > On Wed, Mar 4, 2020 at 9:36 AM Dominick Grift
> > > > <dominick.grift@defensec.nl> wrote:
> > > >>
> > > >> On Wed, Mar 04, 2020 at 09:22:42AM -0500, Stephen Smalley wrote:
> > > >> > 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():
> > > >>
> > > >> # 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)
> > > >
> > > > This shows that your libselinux is still calling
> > > > security_compute_user() from get_ordered_context_list().
> > > > In this case, because the source context is allowed to transition to
> > > > many other contexts, the result returned via
> > > > /sys/fs/selinux/user would exceed the maximum size supported by the
> > > > kernel interface (one page of contexts),
> > > > and therefore it fails.  Then get_ordered_context_list() falls back to
> > > > the failsafe_context.
> > > >
> > > > If you update to libselinux git, you will stop using
> > > > security_compute_user() and hence /sys/fs/selinux/user entirely.
> > > 
> > > FYI I've just built libselinux-3.0-4.fc32 [1] and libselinux-3.0-4.fc33
> > > [2] with the security_compute_user() patch applied.
> > > 
> > > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474378
> > > [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=1474377
> > 
> > Thanks, trying it out
> 
> [root@myguest ~]# strace -s 4096 -o trace.txt selinuxconlist wheel.id sys.id:sys.role:sys.isid:s0
> wheel.id:wheel.role:user.systemd.subj:s0
> wheel.id:sys.role:sys.isid:s0
> 
> So that result looks promising, but when I login I still get wheel.id:sys.role:sys.isid:s0
> Is that some compatibility related thing, or does something else need to be rebuilt against this libselinux for it to work?

Never mind , seems i needed a reboot. works now, Thanks!

> 
> > > 
> > > -- 
> > > ()  ascii ribbon campaign - against html e-mail 
> > > /\  www.asciiribbon.org   - against proprietary attachments
> > > 
> > 
> > -- 
> > gpg --locate-keys dominick.grift@defensec.nl
> > Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> > Dominick Grift
> 
> 
> 
> -- 
> gpg --locate-keys dominick.grift@defensec.nl
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift



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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Stephen Smalley]

On Wed, Mar 4, 2020 at 2:30 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
> Some semi irrelevant background:
>
> I am designing an improved "targeted" policy. Common targeted policies
> are inefficient because they have several "unconfined" domains.
> Unconfined domains are expensive because they have a lot of rules associated with them.
> They're essentially all the same. Just duplicates.

Why can't you just define a single unconfined attribute with
associated allow rules, and then define multiple domains that
have that attribute?  Where is the duplication occurring?  Name-based
type transitions?  IMHO, those should be used far more
sparsely than they are presently in Fedora and there has been some
optimization recently in how they are internally represented.

> I decided to have just one unconfined domain: "the system", and everything that is not targeted ends up in the system domain.
> So now I want to have a confined login shell with role access to the system a'la: staff_u:staff_r:staff_t -> staff_u:unconfined_r:unconfined_t
> pam_selinux seemingly cannot deal with this scenario as shown above. pam_selinux has many other issues. One of them is its concept of
> "default_type". There is no such thing as a "default_type" and implying that there is a "default_type" causes issues.

default_type was to support providing a default type to use when only
a role was specified to e.g. newrole or pam_selinux.  Not sure that's
a problem.

> There are other issues related to this as well: the env_params option depends on the "context contains" access vector being present.
> It will not work even if you have handle_unknown=allow set.

Probably needs to be converted to using selinux_check_access().

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2770 bytes --]

On Wed, Mar 04, 2020 at 09:40:17AM -0500, Stephen Smalley wrote:
> On Wed, Mar 4, 2020 at 2:30 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
> > Some semi irrelevant background:
> >
> > I am designing an improved "targeted" policy. Common targeted policies
> > are inefficient because they have several "unconfined" domains.
> > Unconfined domains are expensive because they have a lot of rules associated with them.
> > They're essentially all the same. Just duplicates.
> 
> Why can't you just define a single unconfined attribute with
> associated allow rules, and then define multiple domains that
> have that attribute?  Where is the duplication occurring?  Name-based
> type transitions?  IMHO, those should be used far more
> sparsely than they are presently in Fedora and there has been some
> optimization recently in how they are internally represented.

Practically yes name-based type transitions but other than that it makes the experience much simpler if you have just one unconfined system domain.
I actually kind of got that idea from you when you mentioned the three domain model.

It works reasonably nicely with exception of this pam_selinux issue.

> 
> > I decided to have just one unconfined domain: "the system", and everything that is not targeted ends up in the system domain.
> > So now I want to have a confined login shell with role access to the system a'la: staff_u:staff_r:staff_t -> staff_u:unconfined_r:unconfined_t
> > pam_selinux seemingly cannot deal with this scenario as shown above. pam_selinux has many other issues. One of them is its concept of
> > "default_type". There is no such thing as a "default_type" and implying that there is a "default_type" causes issues.
> 
> default_type was to support providing a default type to use when only
> a role was specified to e.g. newrole or pam_selinux.  Not sure that's
> a problem.

Its also used by pam_selinux env_params (which in turn is used by ssh for "ssh user/role/level@host")
The problem is that the default_type for ssh and sudo sessions may differ (ie. default_type is not really a default_type)

Ex. joe's default type for sudo might be joe_r:joe_t, but for ssh it might be joe_r:joe_ssh_t

> 
> > There are other issues related to this as well: the env_params option depends on the "context contains" access vector being present.
> > It will not work even if you have handle_unknown=allow set.
> 
> Probably needs to be converted to using selinux_check_access().

We hit that same isssue when we revisted mdp a while ago. Removing the env_params was a quick fix for that then.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: strange pam selinux issue

[Stephen Smalley]

On Wed, Mar 4, 2020 at 9:47 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
> Practically yes name-based type transitions but other than that it makes the experience much simpler if you have just one unconfined system domain.
> I actually kind of got that idea from you when you mentioned the three domain model.

Not sure that was me but whatever.

> Its also used by pam_selinux env_params (which in turn is used by ssh for "ssh user/role/level@host")
> The problem is that the default_type for ssh and sudo sessions may differ (ie. default_type is not really a default_type)

Fair enough; originally it was only used by newrole and only if a type
wasn't explicitly specified via -t.  Maybe
get_default_context_with_role(3)
would be better since it can take into account the caller context.

> > Probably needs to be converted to using selinux_check_access().
>
> We hit that same isssue when we revisted mdp a while ago. Removing the env_params was a quick fix for that then.

Well, the right fix is to use selinux_check_access().

Re: strange pam selinux issue

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On Wed, Mar 04, 2020 at 10:19:54AM -0500, Stephen Smalley wrote:
> On Wed, Mar 4, 2020 at 9:47 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
> > Practically yes name-based type transitions but other than that it makes the experience much simpler if you have just one unconfined system domain.
> > I actually kind of got that idea from you when you mentioned the three domain model.
> 
> Not sure that was me but whatever.

That is what I thought when you mentioned it, but I am glad you did because I was a bit too focussed on least privilege.
A bit of corner cutting here and there can be a good thing. Besides it is fun to explore alternatives.

> 
> > Its also used by pam_selinux env_params (which in turn is used by ssh for "ssh user/role/level@host")
> > The problem is that the default_type for ssh and sudo sessions may differ (ie. default_type is not really a default_type)
> 
> Fair enough; originally it was only used by newrole and only if a type
> wasn't explicitly specified via -t.  Maybe
> get_default_context_with_role(3)
> would be better since it can take into account the caller context.
> 
> > > Probably needs to be converted to using selinux_check_access().
> >
> > We hit that same isssue when we revisted mdp a while ago. Removing the env_params was a quick fix for that then.
> 
> Well, the right fix is to use selinux_check_access().

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]