AVC alerts for process working in /var/lib/sss

[Brian J. Murrell]

I am getting some SELinux AVC alerts for a given process in a given domain that seems to want to be able to read files in /var/lib/sss/.

strace(1)ing the (unprivileged) process it seem to want to do the following:

4024612 openat(AT_FDCWD, "/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)

and

4024612 connect(3, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/nss"}, 110) = -1 EACCES (Permission denied)

in /var/lib/sss/ which as you can see SELinux is currently denying.  But nothing about the running of the process seems to be a-miss despite these EPERMs

Ultimately I am just trying to gauge the potential issues with following the least-privilege principle and setting these to ignore rather than allow.  I.e. what might not be functioning correctly (even though they appear to be from all outward appearances) if these EPERMs continue instead of being allowed.

Any ideas why this process would be wanting to access those paths and why and what the problem might be with denying it?

Cheers,
b.

[Alexey Tikhonov]

Hi,

What OS are running on your system?

What is the output of `cat /etc/nsswitch.conf | grep passwd` on your system?

Do you use SSSD on purpose?

On Tue, Mar 15, 2022 at 7:45 PM Brian J. Murrell 
wrote:
> I am getting some SELinux AVC alerts for a given process in a given domain
> that seems to want to be able to read files in /var/lib/sss/.
>
> strace(1)ing the (unprivileged) process it seem to want to do the
> following:
>
> 4024612 openat(AT_FDCWD, "/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) =
> -1 EACCES (Permission denied)
>
> and
>
> 4024612 connect(3, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/nss"},
> 110) = -1 EACCES (Permission denied)
>
> in /var/lib/sss/ which as you can see SELinux is currently denying.  But
> nothing about the running of the process seems to be a-miss despite these
> EPERMs
>
> Ultimately I am just trying to gauge the potential issues with following
> the least-privilege principle and setting these to ignore rather than
> allow.  I.e. what might not be functioning correctly (even though they
> appear to be from all outward appearances) if these EPERMs continue instead
> of being allowed.
>
> Any ideas why this process would be wanting to access those paths and why
> and what the problem might be with denying it?
>
> Cheers,
> b.
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Brian J. Murrell]

> Hi,

Hi.
> What OS are running on your system?

EL8.5
> What is the output of `cat /etc/nsswitch.conf | grep passwd` on your
> system?

passwd:     sss files systemd
> Do you use SSSD on purpose?

Yes.  I use FreeIPA here.

So it's not at all surprising to see these /var/lib/sss accesses.  I
just want to understand what they might be for and why nothing is
(apparently) breaking due to the accesses being denied, and if that's a
condition that can continue to happen without there being some future
fall-out.  I.e. what is the result of those accesses being denied
instead of being allowed?

Cheers,
b.

[Alexey Tikhonov]

On Wed, Mar 16, 2022 at 11:39 AM Brian J. Murrell 
wrote:
> > Hi,
>
> Hi.
> > What OS are running on your system?
>
> EL8.5

Did you tune any default selinux policies?
> > What is the output of `cat /etc/nsswitch.conf | grep passwd` on your
> > system?
>
> passwd:     sss files systemd

You might want to consider:
 - changing the order to: 'files sss ...'
and
 - setting `enable_files_domain = false` (see `man sssd.conf` for details)
> > Do you use SSSD on purpose?
>
> Yes.  I use FreeIPA here.

Does `getent passwd $your_ipa_use` work for you?
> So it's not at all surprising to see these /var/lib/sss accesses.  I
> just want to understand what they might be for and why nothing is
> (apparently) breaking due to the accesses being denied,

Most probably those are lookups (`getpwnam()`, etc) of local users.
When SSSD fails to serve this lookup, it's being served by next source in
your nsswitch.conf (i.e. 'files')
> and if that's a
> condition that can continue to happen without there being some future
> fall-out.  I.e. what is the result of those accesses being denied
> instead of being allowed?

If client app can't connect to the sssd_nss responder socket, then any SSSD
lookup should fail...

[Brian J. Murrell]

On Wed, 2022-03-16 at 12:20 +0100, Alexey Tikhonov wrote:
> Did you tune any default selinux policies?

No.
> You might want to consider:
>  - changing the order to: 'files sss ...'

But since all of my users are in FreeIPA, won't files more or less be a
noop and sss will always still be consulted?
> and
>  - setting `enable_files_domain = false` (see `man sssd.conf` for
> details)
> Does `getent passwd $your_ipa_use` work for you?

Yes.

To be clear here, I am not saying sssd is not working.  I am saying
that a shell script being executed from a given (non-regular-user)
domain is raising AVCs and I just want to know what the particular
accesses it's requesting are actually needed or not.
> Most probably those are lookups (`getpwnam()`, etc) of local users.
> When SSSD fails to serve this lookup, it's being served by next
> source in
> your nsswitch.conf (i.e. 'files')

But the entry for regular users won't exist there.  So what could break
then?

Cheers,
b.

[Lukas Slebodnik]

On (15/03/22 18:45), Brian J. Murrell wrote:
> I am getting some SELinux AVC alerts for a given process in a given domain that seems to want to be able to read files in /var/lib/sss/.
>
> strace(1)ing the (unprivileged) process it seem to want to do the following:
>
> 4024612 openat(AT_FDCWD, "/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)

Could you share ful reposort fom audit ?
e.g. ausearch -m AVC

Could you share SELinux context of affected files and directories?

e.g.
ls -lZ /var/lib/sss/ /var/lib/sss/*/

LS

[Brian J. Murrell]

On Wed, 2022-03-16 at 14:47 +0100, Lukas Slebodnik wrote:
> Could you share ful reposort fom audit ?
> e.g. ausearch -m AVC

There are lots.  One such example, and the first one of a series:

type=PROCTITLE msg=audit(1647710324.067:172072): proctitle=7368002D63002F686F6D652F6D6F74696F6E2F6D6F7669655F656E642032002026
type=SYSCALL msg=audit(1647710324.067:172072): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5573bf195680 a2=80000 a3=0 items=0 ppid=967054 pid=3299344 auid=4294967295 uid=982 gid=39 euid=982 suid=982 fsuid=982 egid=39 sgid=39 fsgid=39 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:motion_t:s0 key=(null)
type=AVC msg=audit(1647710324.067:172072): avc:  denied  { search } for  pid=3299344 comm="sh" name="sss" dev="dm-8" ino=210 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
> Could you share SELinux context of affected files and directories?
>
> e.g.
> ls -lZ /var/lib/sss/ /var/lib/sss/*/

That's a lot of files, particularly in /var/lib/sss/db/.  The relevant
files I think are:

drwxr-xr-x. 10 root root system_u:object_r:sssd_var_lib_t:s0  4096 Feb  2 05:24 /var/lib/sss/                                                                                      
drwx------. 2 sssd sssd system_u:object_r:sssd_var_lib_t:s0 36864 Mar 19 13:17 /var/lib/sss/db

dm-8 inode 210:

# ls -lid /var/lib/sss
210 drwxr-xr-x. 10 root root 4096 Feb  2 05:24 /var/lib/sss

Cheers,
b.

[Lukas Slebodnik]

On (19/03/22 13:26), Brian J. Murrell wrote:
> On Wed, 2022-03-16 at 14:47 +0100, Lukas Slebodnik wrote:
> > Could you share ful reposort fom audit ?
> > e.g. ausearch -m AVC
>
> There are lots.  One such example, and the first one of a series:
>
> type=PROCTITLE msg=audit(1647710324.067:172072): proctitle=7368002D63002F686F6D652F6D6F74696F6E2F6D6F7669655F656E642032002026
> type=SYSCALL msg=audit(1647710324.067:172072): arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=5573bf195680 a2=80000 a3=0 items=0 ppid=967054 pid=3299344 auid=4294967295 uid=982 gid=39 euid=982 suid=982 fsuid=982 egid=39 sgid=39 fsgid=39 tty=(none) ses=4294967295 comm="sh" exe="/usr/bin/bash" subj=system_u:system_r:motion_t:s0 key=(null)
> type=AVC msg=audit(1647710324.067:172072): avc:  denied  { search } for  pid=3299344 comm="sh" name="sss" dev="dm-8" ino=210 scontext=system_u:system_r:motion_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0

Looks like there is not any issue with SELinux labeling for sssd but issue is
that motion(scontext=system_u:system_r:motion_t:s0) is not allowed to communicate with sssd.

Looks like it tries to use nsswitch which hits sssd due to `sss` as 1st one in
/etc/passwd.

IIRC it should be allowed by default with macros `auth_read_passwd` or
`auth_use_nsswitch` in recent version of fedora. I am not sure about el8.

I would recommend to file a bug to selinux-policy.

BTW changing order of modules in /etc/passwd `sss files` -> `files sss`
might avoid issues with AVCs.

HTH

LS