SELinux Archive on lore.kernel.org
 help / color / Atom feed
* [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, back to index

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

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org
	public-inbox-index selinux

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git