From: dac.override@gmail.com (Dominick Grift) Date: Sun, 14 Aug 2016 13:49:16 +0200 Subject: [refpolicy] [PATCH] staff: Allow dbus chat with accountsd_t for LightDM In-Reply-To: <6da335f0-c7dc-2473-494e-4d043f59173d@ieee.org> References: <1470643811-32586-1-git-send-email-jason@perfinion.com> <100ba9a1-779f-8fa1-9012-9d1b17c655bc@gmail.com> <6da335f0-c7dc-2473-494e-4d043f59173d@ieee.org> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/13/2016 02:50 PM, Chris PeBenito wrote: > On 08/08/16 11:07, Dominick Grift wrote: >> On 08/08/2016 10:10 AM, Jason Zaman wrote: >>> LightDM is split into two parts: the main part and greeter. The >>> greeter logs in >>> as root so switches to staff_t and is not in xdm_t anymore and needs >>> to get the >>> list of users. It crashes and fails to start without this. >> >> I am not expecting any changes here but for the record i will still >> leave a comment. >> >> It is transitioning to the login shell domain because it is told to. In >> DSSP this is handled differently for the various login programs (except >> local login) >> >> Instead of telling it with pam_selinux to transition to the login shell >> domain , it is told to transition to a prefixed login program domain. In >> this scenario for example staff_xdmuser_t. The transition to the login >> shell domain happens based on the prefix when the actual login shell is >> run (probably after xsession). >> >> Using that approach the login shell does not end up with permissons a >> login shell does not need. All these permissions required because login >> programs transition too early to the login shell domain really add up >> >> Same with for example sshd, by transitioning too early you have to >> associate the permisisons that sshd needs for functionality such as X >> forwarding, tunnelling etc with the login shell domain. > > I have been concerned about what you're describing (particularly for > sshd) for some time. I would prefer to fix things the correct way. I > am open to new login domains to better fix these types of problems. > Patches, even if just to put together a skeleton, would be appreciated. > i.e. it doesn't have to fully work in enforcing, but at least set up the > new domains and transitions. > > In refpolicy i would at least initially focus on dealing with this for sshd first. Because that is simpler than desktop managers, and the benefits will be more visible and more compelling. That will also then serve as a proof of concept. Doing this for desktop managers will not show the benefits unless you confine the desktop as well. So if you start there then it may not seem compelling to you since many of the permisisons you would be able to shave off if you would confine the desktop would still be needed when you run the desktop in the login shell domain (for example gnome control center will need to system bus chat with accountsd) -- 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: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/cf84a4d1/attachment.bin