On Mon, 2004-04-12 at 13:06, Russell Coker wrote: > We discussed this at length and came to the conclusion that running a GNOME or > KDE environment in a privileged role is a bad idea. The problem is that it's going to happen. E.g. if you log in as a staff_r, then inside a terminal use 'su' to become root/sysadm_r, and run a program that uses X. > Also GNOME and KDE > create lots of /tmp entries such as /tmp/mcop-user and /tmp/.gconf-user. If > you login to GNOME or KDE as one role and then login as the same UID with > another role then one of two things will happen: > > 1) role A is not permitted to write to role B's /tmp files and the login will > fail in ways that might be surprising and difficult to debug. > > 2) role A is permitted to write to role B's /tmp files, things will work BUT > role A can probably use this to take over role B processes. If we permit > this bi-directionally so that no combination of X login order will result in > failure then we give role A and role B such access to each other that we > should just merge them. There's a third option - write policy such that only for those shared files, each role can access the other's files. That's what I'm working on right now with GConf. > The conclusion is that there is no benefit in giving the user two roles and > allowing them both to be accessed through a GUI login. Although we don't have SE-X yet, making most of this moot, I think it's still a worthwhile goal.
Attachment:
signature.asc
Description: This is a digitally signed message part
