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.
Cheers,
Nicolas
Nicolas Iooss <[email protected]> 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)
>
> Cheers,
> Nicolas
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
On 1/6/19 2:33 AM, Dominick Grift wrote:
> Nicolas Iooss <[email protected]> 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
Chris PeBenito <[email protected]> writes:
> On 1/6/19 2:33 AM, Dominick Grift wrote:
>> Nicolas Iooss <[email protected]> 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.
I agree, but it gets hard to maintain if you split all the individual
nss modules.
The solution i implemented in my policy also has its limitations and
assumptions, and is pretty much all or almost nothing.
Atleast you have the init_systemd tunable which atleast addresses the
various nss_systemd modules to some degree.
I only allow my confined unpriv users to read passwd and nss config, the
drawback of this is that these shells cannot use /proc/net/"protocol"
which is nice on the one hand for confined shells but it "breaks" bash
Its a tough issue
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
On Sun, Jan 6, 2019 at 8:27 PM Dominick Grift <[email protected]> wrote:
>
> Chris PeBenito <[email protected]> writes:
>
> > On 1/6/19 2:33 AM, Dominick Grift wrote:
> >> Nicolas Iooss <[email protected]> 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.
>
> I agree, but it gets hard to maintain if you split all the individual
> nss modules.
>
> The solution i implemented in my policy also has its limitations and
> assumptions, and is pretty much all or almost nothing.
>
> Atleast you have the init_systemd tunable which atleast addresses the
> various nss_systemd modules to some degree.
>
> I only allow my confined unpriv users to read passwd and nss config, the
> drawback of this is that these shells cannot use /proc/net/"protocol"
> which is nice on the one hand for confined shells but it "breaks" bash
>
> Its a tough issue
All right, I agree restricting auth_use_nsswitch() and auth_use_pam()
is tough, and I do not have enough time of take care of this issue by
creating a new minimal interface.
Moreover, when I see users of auth_use_nsswitch(), I have the
impression that most of them use it for host name resolution, which
does not use nss-systemd module. Therefore I also agree with only
adding init_dbus_chat(sshd_t) for the issue I had, which is what
commit ef6c7f155e10 ("systemd misc") did.
Thanks for your comments.
Nicolas