* nss-systemd D-Bus call caused by getpwent @ 2019-01-05 23:23 Nicolas Iooss 2019-01-06 7:33 ` Dominick Grift 0 siblings, 1 reply; 5+ messages in thread From: Nicolas Iooss @ 2019-01-05 23:23 UTC (permalink / raw) To: selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nss-systemd D-Bus call caused by getpwent 2019-01-05 23:23 nss-systemd D-Bus call caused by getpwent Nicolas Iooss @ 2019-01-06 7:33 ` Dominick Grift 2019-01-06 18:56 ` Chris PeBenito 0 siblings, 1 reply; 5+ messages in thread From: Dominick Grift @ 2019-01-06 7:33 UTC (permalink / raw) To: Nicolas Iooss; +Cc: selinux-refpolicy Nicolas Iooss <nicolas.iooss@m4x.org> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nss-systemd D-Bus call caused by getpwent 2019-01-06 7:33 ` Dominick Grift @ 2019-01-06 18:56 ` Chris PeBenito 2019-01-06 19:27 ` Dominick Grift 0 siblings, 1 reply; 5+ messages in thread From: Chris PeBenito @ 2019-01-06 18:56 UTC (permalink / raw) To: Dominick Grift, Nicolas Iooss; +Cc: selinux-refpolicy On 1/6/19 2:33 AM, Dominick Grift wrote: > Nicolas Iooss <nicolas.iooss@m4x.org> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nss-systemd D-Bus call caused by getpwent 2019-01-06 18:56 ` Chris PeBenito @ 2019-01-06 19:27 ` Dominick Grift 2019-01-06 21:37 ` Nicolas Iooss 0 siblings, 1 reply; 5+ messages in thread From: Dominick Grift @ 2019-01-06 19:27 UTC (permalink / raw) To: Chris PeBenito; +Cc: Nicolas Iooss, selinux-refpolicy Chris PeBenito <pebenito@ieee.org> writes: > On 1/6/19 2:33 AM, Dominick Grift wrote: >> Nicolas Iooss <nicolas.iooss@m4x.org> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nss-systemd D-Bus call caused by getpwent 2019-01-06 19:27 ` Dominick Grift @ 2019-01-06 21:37 ` Nicolas Iooss 0 siblings, 0 replies; 5+ messages in thread From: Nicolas Iooss @ 2019-01-06 21:37 UTC (permalink / raw) To: Dominick Grift, Chris PeBenito; +Cc: selinux-refpolicy On Sun, Jan 6, 2019 at 8:27 PM Dominick Grift <dac.override@gmail.com> wrote: > > Chris PeBenito <pebenito@ieee.org> writes: > > > On 1/6/19 2:33 AM, Dominick Grift wrote: > >> Nicolas Iooss <nicolas.iooss@m4x.org> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-01-06 21:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-05 23:23 nss-systemd D-Bus call caused by getpwent Nicolas Iooss 2019-01-06 7:33 ` Dominick Grift 2019-01-06 18:56 ` Chris PeBenito 2019-01-06 19:27 ` Dominick Grift 2019-01-06 21:37 ` Nicolas Iooss
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).