On Mon, 2007-02-12 at 14:43 -0500, Alan Cox wrote: > On Mon, Feb 12, 2007 at 01:48:26PM -0500, David Zeuthen wrote: > > Two sessions in fast user switching on a single seat. One web cam. You > > really want to make sure that the inactive session cannot use the web > > cam. Yes, to do this in a really secure manner you want revoke() and > > No you don't. You want to make sure that only the user uid of the currently > active session can access the webcam. It doesn't matter if the webcam > access then comes from my X session or some other unrelated process, providing > it's me it is watching. Correct me if I'm wrong, but today, access to hardware solely relies on whether you can get a file descriptor. This most of the time means that you need to be able to open a device file (ignoring crazy things like SUSE's now defunct resmgr that passes fd's over a socket). Hence, the proposal here is to just manage the permissions, via ACL's, on said device files. And of course revoke() after having removed the ACL. Are you suggesting something else than relying on ACL + revoke()? That would seem to make the system more complex perhaps... Just saying that today's model on hardware access from user space is well understood... > Trivial example is a user running cron to take 5 minute shots of their activity > via cron. The cron fired video grab is definitely not part of some gnome > created session but its perfectly fine. What must fail is if I try and > take a picture while I've let someone else borrow the seat (and this again > is uid not session) That's an interesting example. So perhaps the ACL management system should have a notion of letting people say "apply these ACL's if, and only if, no seat is claiming the device". There's a bug open on this you might want to look at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140853 As I'm putting ACL management into HAL (see the proposal in the link in comment 18) putting stuff like "apply these ACL's if, and only if, no seat is claiming the device" is a real possibility. Then again, I'm not really sure whether it's worth the complexity. It might be. > > probably something even better than this proposal > > SELinux can do much of the revoke type duties, but I agree you want revoke > really, and its a big Linux failing. Please beat up Al Viro until he > understands how urgent it is... Sure! I'm not sure he listens to me though. Another point is that all this effort happens upstream (for better and worse) so I'm not sure how much we can rely on SELinux. David -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
