RE: Postfix with home dirs on GPFS

[Luke Sudbery]

Great  - thank you. We had set fcontext equivalence:


[root@host-name ~]# semanage fcontext -C -l



SELinux Local fcontext Equivalence



/var/adm/ras = /var/log

/gpfs-fs/homes/a = /home

/gpfs-fs/homes/b = /home

/gpfs-fs/homes/c = /home

/gpfs-fs/homes/d = /home

/gpfs-fs/homes/e = /home

/gpfs-fs/homes/f = /home

/gpfs-fs/homes/g = /home

/gpfs-fs/homes/h = /home

/gpfs-fs/homes/i = /home

/gpfs-fs/homes/j = /home

/gpfs-fs/homes/k = /home

/gpfs-fs/homes/l = /home

/gpfs-fs/homes/m = /home

/gpfs-fs/homes/n = /home

/gpfs-fs/homes/o = /home

/gpfs-fs/homes/p = /home

/gpfs-fs/homes/q = /home

/gpfs-fs/homes/r = /home

/gpfs-fs/homes/s = /home

/gpfs-fs/homes/t = /home

/gpfs-fs/homes/u = /home

/gpfs-fs/homes/v = /home

/gpfs-fs/homes/w = /home

/gpfs-fs/homes/x = /home

/gpfs-fs/homes/y = /home

/gpfs-fs/homes/z = /home

[root@host-name ~]#

And run restorecon on one of the home directories itself, but not on the paths above it.
Doing this seems to have fixed the problem without the need for an additional module. In
fact it appears to have been the mount point of the file system that was the problem, so
restorecon needs running on every machine.

Great. But I’m a still bit confused about the need to add home_root_t to the new home dir
roots and to have the equivalency rule – don’t they achieve the same thing?

Many thanks,

Luke
--
Luke Sudbery
Architecture, Infrastructure and Systems
Advanced Research Computing, IT Services
Room 132, Computer Centre G5, Elms Road

Please note I don’t work on Monday.

From: d.sastre.medina(a)gmail.com <d.sastre.medina(a)gmail.com&gt;
Sent: 27 May 2021 14:19
To: Luke Sudbery (Advanced Research Computing) <L.R.Sudbery(a)bham.ac.uk&gt;
Cc: selinux(a)lists.fedoraproject.org
Subject: Re: Postfix with home dirs on GPFS

Hello Luke,

If you are relocating home directories somewhere else (not /home), you need to make sure
those new home directories are properly labeled. As you can see in the AVC denials, those
directories/files are unlabeled_t.

The semanage-fcontext(8) manual page contains an example:

       # semanage fcontext -a -t home_root_t "/disk6"
       # semanage fcontext -a -e /home /disk6/home
       # restorecon -R -v /disk6

Obviously, you need to replace the paths in the example with the ones on your use case.

Hope that helps.



On Thu, May 27, 2021 at 1:16 PM Luke Sudbery
<[e-mail]<mailto:[e-mail]>> wrote:
Hello,

With home directories on IBM Spectrum Scale and selinux enabled, postfix is unable to
deliver locally. This is using RHELS8.3.

Postfix logs:


May 27 10:23:20 host-name postfix/local[1245962]: A1219F9E:
to=<[e-mail]<mailto:[e-mail]>>,
orig_to=<username>, relay=local, delay=0.03, delays=0.01/0.01/0/0.01, dsn=5.2.0,
status=bounced (cannot update mailbox /gpfs-fs/homes/u/username/Mailbox for user username.
unable to create lock file /gpfs-fs/homes/u/username/Mailbox.lock: Permission denied)

Although the actual problem is that it can’t/doesn’t read ~/.forward to know where to
really send the mail.

Selinux audit logs show:


type=AVC msg=audit(1622111726.610:10854499): avc:  denied  { search } for  pid=1315267
comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir permissive=0

type=SYSCALL msg=audit(1622111726.610:10854499): arch=c000003e syscall=6 success=no
exit=-13 a0=561f9a316390 a1=7ffdc7e109c0 a2=7ffdc7e109c0 a3=0 items=0 ppid=3375
pid=1315267 auid=4294967295 uid=0 gid=0 euid=606178 suid=0 fsuid=606178 egid=100 sgid=0
fsgid=100 tty=(none) ses=4294967295 comm="local"
exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0
key=(null)ARCH=x86_64 SYSCALL=lstat AUID="unset" UID="root"
GID="root" EUID="username" SUID="root"
FSUID="username" EGID="users" SGID="root"
FSGID="users"

type=AVC msg=audit(1622111726.611:10854500): avc:  denied  { search } for  pid=1315267
comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir permissive=0

type=SYSCALL msg=audit(1622111726.611:10854500): arch=c000003e syscall=4 success=no
exit=-13 a0=561f9a3165c0 a1=7ffdc7e109c0 a2=7ffdc7e109c0 a3=0 items=0 ppid=3375
pid=1315267 auid=4294967295 uid=0 gid=0 euid=606178 suid=0 fsuid=606178 egid=100 sgid=0
fsgid=100 tty=(none) ses=4294967295 comm="local"
exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0
key=(null)ARCH=x86_64 SYSCALL=stat AUID="unset" UID="root"
GID="root" EUID="username" SUID="root"
FSUID="username" EGID="users" SGID="root"
FSGID="users"

type=AVC msg=audit(1622111726.611:10854501): avc:  denied  { search } for  pid=1315267
comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir permissive=0

type=SYSCALL msg=audit(1622111726.611:10854501): arch=c000003e syscall=257 success=no
exit=-13 a0=ffffff9c a1=561f9a316600 a2=c1 a3=0 items=0 ppid=3375 pid=1315267
auid=4294967295 uid=0 gid=0 euid=606178 suid=0 fsuid=606178 egid=100 sgid=0 fsgid=100
tty=(none) ses=4294967295 comm="local"
exe="/usr/libexec/postfix/local" subj=system_u:system_r:postfix_local_t:s0
key=(null)ARCH=x86_64 SYSCALL=openat AUID="unset" UID="root"
GID="root" EUID="username" SUID="root"
FSUID="username" EGID="users" SGID="root"
FSGID="users"

audit2allow shows:


[root@host-name audit]# audit2allow -w -a

type=AVC msg=audit(1622111726.610:10854499): avc:  denied  { search } for  pid=1315267
comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir permissive=0

        Was caused by:

                Missing type enforcement (TE) allow rule.



                You can use audit2allow to generate a loadable module to allow this
access.



type=AVC msg=audit(1622111726.611:10854500): avc:  denied  { search } for  pid=1315267
comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir permissive=0

        Was caused by:

                Missing type enforcement (TE) allow rule.



                You can use audit2allow to generate a loadable module to allow this
access.



type=AVC msg=audit(1622111726.611:10854501): avc:  denied  { search } for  pid=1315267
comm="local" name="/" dev="gpfs" ino=3
scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:unlabeled_t:s0
tclass=dir permissive=0

        Was caused by:

                Missing type enforcement (TE) allow rule.



                You can use audit2allow to generate a loadable module to allow this
access.



[root@host-name audit]# audit2allow -a





#============= postfix_local_t ==============

allow postfix_local_t unlabeled_t:dir search;

[root@host-name audit]#

Creating a module using these rules fixes the problem.

I’ve also tested creating a user with a home directory with GPFS stopped, and using the
same path that a GPFS user would have. This worked without any selinux changes, and
implies this is a problem with home dirs on GPFS, rather than just the path itself.

Should this be reported as a selinux bug?

Many thanks,

Luke

--
Luke Sudbery
Architecture, Infrastructure and Systems
Advanced Research Computing, IT Services
Room 132, Computer Centre G5, Elms Road

Please note I don’t work on Monday.


_______________________________________________
selinux mailing list --
[e-mail]<mailto:[e-mail]>
To unsubscribe send an email to
[e-mail]<mailto:[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.fedoraproject.org/archives/list/[e-mail]...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure