"doing" things to HAL devices

David Zeuthen david at fubar.dk
Tue Mar 15 16:51:57 PST 2005


On Wed, 2005-03-16 at 00:41 +0000, Richard Hughes wrote:
> > Note that distros would also need to specify the security policy here
> > with D-BUS; again, on Fedora I would probably use at_console and perhaps
> > requiring the caller (gnome-power-manager for instance) to run in a
> > specific SELinux security context. Other distros may do different
> > things.
> 
> My personal opinion is that for 99.9% of people, locking down the "who
> can suspend" won't be an option. And the sort of people that will would
> know how to edit a config file to change ALLOWSUSPEND=NO :-)

The point here is really to restrict malware/viruses from doing harm,
e.g. we want only, say, the /usr/bin/gnome-power-manager binary to do
the suspend - for power management etc. it's probably not a big concern
but I imagine this is relevant for other interfaces worth exporting -
such as allowing an authorized user at the console to format/rename his
CompactFlash memory card (and here it would be a bug to ask for the root
password because he is at the console etc.).

Another point is that most desktop bits like GTK+, Qt etc. needs a
secure mode (requires trusted X, secure a11y, no user theme code) for
this to really work but that is another discussion - and a helluva lot
of work!

Cheers,
David





_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list