From: dac.override@gmail.com (Dominick Grift) Date: Sat, 24 Feb 2018 16:35:52 +0100 Subject: [refpolicy] [PATCH] misc dbus patches In-Reply-To: <20180224142701.GA23580@julius.enp8s0.d30> References: <20180213003649.GA17327@xev> <2087459.qDY3ImaCar@liv> <20180223072510.GA3931@julius.enp8s0.d30> <20180224142701.GA23580@julius.enp8s0.d30> Message-ID: <20180224153552.GB23580@julius.enp8s0.d30> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Sat, Feb 24, 2018 at 03:27:01PM +0100, Dominick Grift wrote: > On Sat, Feb 24, 2018 at 09:18:20AM -0500, Chris PeBenito via refpolicy wrote: > > On 02/23/2018 02:25 AM, Dominick Grift via refpolicy wrote: > > > On Fri, Feb 23, 2018 at 03:53:01PM +1100, Russell Coker via refpolicy wrote: > > >> On Friday, 16 February 2018 8:57:48 AM AEDT Chris PeBenito wrote: > > >>> On 02/12/2018 07:36 PM, Russell Coker via refpolicy wrote: > > >>>> Here is a collection of dbus policy patches, all fairly simple. > > >>>> > > >>>> Chris please merge the ones you like and we can discuss any you don't like > > >>>> afterwards. > > >>> > > >>> I merged everything except for the user/groupadd ones, which need > > >>> explanation: what are they doing with dbus exactly? > > >> > > >> sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\1\0\1\t > > >> \0\0\0\2\0\0\0\247\0\0\0\1\1o\0\31\0\0\0/org/freedesktop/ > > >> systemd1\0\0\0\0\0\0\0\3\1s\0\27\0\0\0LookupDynamicUserByName\0\2\1s\0 > > >> \0\0\0org.freedesktop.systemd1.Manager\0\0\0\0\0\0\0\0\6\1s > > >> \0\30\0\0\0org.freedesktop.systemd1\0\0\0\0\0\0\0\0\10\1g\0\1s\0\0", > > >> iov_len=184}, {iov_base="\4\0\0\0zzz2\0", iov_len=9}], msg_iovlen=2, > > >> msg_controllen=0, msg_flags=0}, MSG_DONTWAIT|MSG_NOSIGNAL) = 193 > > >> > > >> The above is from a strace of "groupadd zzz2". It is sending a message to > > >> systemd to lookup dynamic users. I can't find where in the groupadd code it > > >> does this though. I checked the pam configuration and that doesn't appear to > > >> have it. > > > > > > this is nss_systemd. it is an optional systemd nss module. > > > > > > from that perspective one might consider adding it to auth_use_nsswitch() > > > > That does make sense. It does additionally bring up how big that > > interface is getting. Perhaps it should be split up, maybe by the > > nsswitch database (passwd, hosts, networks, etc.) > > The pattern i am currently seeing is nss with or without network (but i may not see the full picture yet) > > so i have a base nss client which just reads /etc/passwd, /etc/nsswitch.conf > and stream connects to sssd if that is installed. > > then theres the full nss, which basically is base + everything else > > https://github.com/DefenSec/dssp2-standard/blob/master/policy/system/nss.cil It is not as black and white though. My decision was colored. Because if you do a ps auxZ on a system that has a process with a dynamic id then ps needs to use nss_systemd similarly if you do an ls in a dir with object assoc. with dynamic ids. But my unpriv user shells are not allowed access to ps system processes, and arent allowed access to list dirs that might have objects with dynamic id's (atleast that is the goal) I try to keep my unpriv shells without network access and without dbus system bus access if possible So i basically either use full nss, or base nss. for everything in between its base nss plus indiviual calls to whatever else it needs its ugly, but its ugly regardless... > > > > > -- > > Chris PeBenito > > _______________________________________________ > > refpolicy mailing list > > refpolicy at oss.tresys.com > > http://oss.tresys.com/mailman/listinfo/refpolicy > > -- > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20180224/5defadc0/attachment.bin