On 1/6/19 2:33 AM, Dominick Grift wrote:
Nicolas Iooss <nicolas.iooss@xxxxxxx> writes:Hi, While testing the current master branch of refpolicy on Arch Linux, I encountered the following denial: type=USER_AVC msg=audit(1546729287.319:440): pid=312 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.systemd1.Manager member=GetDynamicUsers dest=org.freedesktop.systemd1 spid=14828 tpid=1 scontext=system_u:system_r:sshd_t tcontext=system_u:system_r:init_t tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' My OpenSSH server is calling GetDynamicUsers() exposed by systemd over D-Bus. This call comes from systemd's NSSwitch module and occurs when OpenSSH calls setpwent() to get information about a user (https://github.com/systemd/systemd/blob/v240/src/nss-systemd/nss-systemd.c#L676). How should this be handled by refpolicy? For example, would adding a call to init_dbus_chat(nsswitch_domain) in a ifdef(`init_systemd') block be acceptable? This would allow any callers of auth_use_nsswitch() to be able to communicate with systemd's PID 1 over D-Bus.FWIW I have this in my nss macro too, However I have two nss macros, one base macro and one superset that has this call amongst others (mymachines resolve etc) I only give nss base access to my confined users since they will never have access to any objects associated with userns uids/gids anyways so they shouldnt get into a position where they need to resolve them (except confined sysadm)
I've been dissatisfied with what auth_use_nsswitch() and auth_use_pam() have turned into, as I think they're too big. It's not an easy thing to define due them being inherently extensible. What you describe is one possible good direction to go towards. I was also concerned about all of the network access that is allowed by it and thought about splitting out the local accesses into a base interface.
-- Chris PeBenito
