On Mon, Oct 07, 2019 at 06:51:57PM +0200, Dominick Grift wrote:
> On Mon, Oct 07, 2019 at 11:03:44AM -0500, Ian Pilcher wrote:
> > I am hitting this (non-fatal) denial when reloading a service via the
> > systemd dbus API:
> >
> > > type=USER_AVC msg=audit(1570462081.809:743): pid=1 uid=0
> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
> > > msg='avc: denied { status } for auid=n/a uid=0 gid=1001
> > > cmdline="/usr/bin/python2 /usr/local/bin/test.py"
> > > scontext=system_u:system_r:denatc_t:s0
> > > tcontext=system_u:system_r:init_t:s0 tclass=system
> > > exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
> > https://selinuxproject.org/page/NB_ObjectClassesPermissions defines this
> > permission as "Get system status information," which isn't particularly
> > helpful.
> >
> > Ultimately, I need to decide whether to allow or "dontaudit" this
> > denial, so any information/pointers on what systemd is doing here and
> > what functionality I will lose if I dontaudit this denial would be
> > appreciated.
>
> Not sure but this is my best bet:
>
> Generally, i think, its about "getting" information from systemd1, as opposed to setting things.
>
> Stuff like: introspection, getting info about objects it manages, about it's properties.
>
> Theres a lot of "status information" to be gotten I guess. Introspect systemd1 to see what all is there.
>
> But if you reload a unit, I gather, you might get some status information about it from systemd1.
>
> I guess you can probably see the methods that are being invoked if you set the systemd loglevel to debug
>
> systemd-analyze log-level debug && systemctl reload foo && journalctl -rb
I tried it out with simple `systemctl status`
Oct 07 19:04:21 myguest systemd[1]: Sent message type=method_return sender=org.freedesktop.systemd1 destination=n/a path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=a{sv} error-name=n/a error-message=n/a
Oct 07 19:04:21 myguest systemd[1]: SELinux access check scon=wheel.id:sysadm.role:systemctl.sysadm.subj:s0 tcon=sys.id:sys.role:systemd.system.subj:s0 tclass=system perm=status path=(null) cmdline=: 0
Oct 07 19:04:21 myguest systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 signature=s error-name=n/a error-message=n/a
So the method "get all properties from systemd1" was called by running that, and that triggered a "system status" check
>
> >
> > Thanks!
> >
> > --
> > ========================================================================
> > Ian Pilcher arequipeno@xxxxxxxxx
> > -------- "I grew up before Mark Zuckerberg invented friendship" --------
> > ========================================================================
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
