* [systemd SELinux] system status permission
@ 2019-10-07 16:03 Ian Pilcher
2019-10-07 16:51 ` Dominick Grift
0 siblings, 1 reply; 4+ messages in thread
From: Ian Pilcher @ 2019-10-07 16:03 UTC (permalink / raw)
To: selinux, Systemd
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.
Thanks!
--
========================================================================
Ian Pilcher arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [systemd SELinux] system status permission 2019-10-07 16:03 [systemd SELinux] system status permission Ian Pilcher @ 2019-10-07 16:51 ` Dominick Grift 2019-10-07 17:09 ` Dominick Grift 0 siblings, 1 reply; 4+ messages in thread From: Dominick Grift @ 2019-10-07 16:51 UTC (permalink / raw) To: Ian Pilcher; +Cc: selinux, Systemd [-- Attachment #1: Type: text/plain, Size: 2097 bytes --] 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 > > Thanks! > > -- > ======================================================================== > Ian Pilcher arequipeno@gmail.com > -------- "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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [systemd SELinux] system status permission 2019-10-07 16:51 ` Dominick Grift @ 2019-10-07 17:09 ` Dominick Grift 2019-10-07 18:31 ` Ian Pilcher 0 siblings, 1 reply; 4+ messages in thread From: Dominick Grift @ 2019-10-07 17:09 UTC (permalink / raw) To: Ian Pilcher, selinux, Systemd [-- Attachment #1: Type: text/plain, Size: 3297 bytes --] 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@gmail.com > > -------- "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 #2: signature.asc --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [systemd SELinux] system status permission 2019-10-07 17:09 ` Dominick Grift @ 2019-10-07 18:31 ` Ian Pilcher 0 siblings, 0 replies; 4+ messages in thread From: Ian Pilcher @ 2019-10-07 18:31 UTC (permalink / raw) To: selinux, Systemd On 10/7/19 12:09 PM, Dominick Grift wrote: > > 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 for checking this out. I does indeed seem that this check is triggered by the 'systemctl status' command (or which I was previously unaware). It isn't, however, triggered by 'systemctl status $UNIT'; that check looks like: Oct 07 13:20:45 c7.penurio.us systemd[1]: SELinux access check scon=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcon=unconfined_u:object_r:radvd_dynamic_unit_file_t:s0 tclass=service perm=status path=/etc/systemd/system/radvd.service cmdline=systemctl status radvd.service: 0 I.e. the target context type is that of the unit file. Looks like this is going to be a dontaudit, since my service has no business looking at the overall system state. -- ======================================================================== Ian Pilcher arequipeno@gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ======================================================================== ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-10-07 18:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-07 16:03 [systemd SELinux] system status permission Ian Pilcher 2019-10-07 16:51 ` Dominick Grift 2019-10-07 17:09 ` Dominick Grift 2019-10-07 18:31 ` Ian Pilcher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).