Currently, xscreensaver runs as a user with setuid root. It changes its euid to user before execing the fancy programs (hacks), and the unlock GUI is execed in the similar manner.
So, unlock GUI runs with user privs and setuid root turned off, and has a dual pipe connection with xscreensaver daemon. The pam conversation function is in the daemon and euid is changed back to root before running PAM stack. The messages coming from PAM stack are displayed on the GUI by writing on one of the pipe connections. The user entered data (actual password or whatever PAM asked the user for) is written on the other pipe which the daemon is watching and hence gets sent back to the PAM stack. Anyone can simply call the unlock GUI at /usr/openwin/lib/xscreensaver/bin/xscreensaver-lock and it will come up but be the dummy GUI. My assumption was since the xscreensaver daemon has a hard wired path to xscreensaver-lock mentioned above, which is in only root write accessible area of file system we are maintaining trusted path. Would this conform to trusted path requirement and if not can someone please define trusted path in layman terms ;-) --mahmood Darren J Moffat wrote: > Bill Sommerfeld wrote: >> On Thu, 2008-03-06 at 17:09 -0600, Brian Cameron wrote: >>> However, it is unclear >>> to me whether Trusted Path applies to non-Trusted environments >> >> IMHO it is valid concept in any multi-user environment. Not clear we >> have hard requirements for it outside Trusted but if we don't it's only >> because our customers aren't paranoid enough... > > We should have though. We shouldn't be encouraging users to enter or > change any credentials for intial login or screen lock or password > change through anything but a trusted path. > > Once we have things like fast user switching this becomes even more an > issue since you need to trust the thing you are entering your creds > into isn't running as the user you are switching away from. > > I don't know if what MacOS X does would be considered Trusted Path. > However I do have a recollection that what Windows does (for initial > login, screen lock and password change) was called out as a Trusted > Path mechanism in one of their Common Criteria evaluations and > Windows doesn't have multi level security. > > Trusted Path does not imply multi level security (labeling, MAC what > ever name you want it to go by) they are independent concepts. > However when you have labeling you really need a Trusted Path, but > ideally you should have it anyway. >
