В Sun, 16 Mar 2025 14:01:01 +0100
Christian Göttsche <
cgzones@googlemail.com> пишет:
With my very limited knowledge of selinux, I don't follow.
Why it would need DAC_READ_SEARCH? If you can provide an example,
it would be great.
postfix services like smtp, smtpd, postfix-master and tlsproxy need
access to `/var/spool/postfix/private/proxymap` and the parent
directory `/var/spool/postfix/private/` is owned by postfix:root with
mode 0700.
Thus processes running as root:root have no standard DAC search
permission for that directory (they are not the owner and there are no
group and other permissions) so the kernel checks access via
capabilities.
For directory search permission DAC_READ_SEARCH is considered first,
but this capability is not granted via the systemd service file.
Then DAC_OVERRIDE is tried, which is granted via the systemd service
file, and finally directory search access is granted.
I wonder if we can get away granting DAC_READ_SEARCH *only*.
Probably not, due to local(8) or virtual(8)..
With an active LSM each capability is checked whether its granted by
the loaded security policy.
So with DAC_READ_SEARCH not granted, since its not in the permitted capability set, SELinux is queried with DAC_OVERRIDE.
Previously, or with DAC_READ_SEARCH added to the permitted capability
set, SELinux is queried with DAC_READ_SEARCH, leading to a less
permissive policy only granting DAC_READ_SEARCH and not DAC_OVERRIDE.
So, why, when SELinux is queried with DAC_OVERRIDE, it doesn't work?
Is it because some pre-existing SELinux rules which relied on
DAC_READ_SEARCH instead of DAC_OVERRIDE?
So it breaks existing setups with particular SELinux rules *only*,
it's not a generic thing but something specific to a particular setup,
right? So if such SELinux ruleset is modified to check for DAC_OVERRIDE, everything works again?
This looks quite a bit twisty :)
Also adding DAC_READ_SEARCH to the permitted capability set does not
expand privileges since the kernel always falls back to DAC_OVERRIDE.
Ok.
p.s.: please send BTS mails also to nnn-submitter@bugs.debian.org
It's interesting, - somehow, for many years, I always assumed that mail
to NNN@bugs.d.o is forwarded to submitter too, automatically, *unless*
the submitter address is specified in To or Cc. Apparently it is not
the case. It's a fun stuff, and I always reply to NNN@bugs.d.o, and
was getting replies, so I wonder how people received my replies..
(I strip the actual submitter address in replies since these days,
people often block *.ru and communication is difficult. Let's see
how direct To: works. I wont add another To like NNN-submitter@, it
is just too much useless work).
Thanks,
/mjt
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)