Re: GNOME and non-linux platforms (release team please stand up)

[David Zeuthen <david fubar dk>]

On Tue, 2009-07-28 at 12:10 -0500, Brian Cameron wrote:
> I have pinged the Sun team working on DeviceKit and suggested they
> be better about communication with upstream by sending some status
> to the devkit-devel mailing list.

Thanks.

> Also, Solaris has a security rule that requires that users not be asked
> to enter passwords for gaining authorization unless they are in the
> trusted path.  To my understanding, PolicyKit does not address this
> issue today, perhaps because most Linux distros are not as strict about
> this requirement.  This technical issue could be overcome, for example,
> by switching to a separate VT in the trusted path to display the
> dialog.

Yes, it is entirely possible to easily make PolicyKit use an
Authentication Agent that runs outside the session. If you wanted you
could even make the authentication agent communicate with a separate
device (for example a separate device connected via USB with small
display / big flashy button the user can press to authenticate the
request) or a mobile phone display (using BT for proximity)... or
whatever... e.g. the APIs are in place for such things.

And, sure, for home/consumer usage just having both the screensaver
unlock dialog, the PolicyKit authentication dialogs and other stuff
(such as GMountOperation interaction [1]) running in a trusted sandbox
(e.g. separate Xserver/VT) is probably what we want. That way, nothing
running in the user session can ever snoop on passwords. Of course this
requires a lot of bug fixes in the X.org stack (it is essentially fast
user switching), we need a system compositor (like wayland), ConsoleKit
changes and so on... so blue sky for now.

Btw, I wonder how you implement screen locking (e.g. screen saver) /
connecting to network shares (e.g. gvfs) / ssh (via the terminal) if you
don't want people to enter passwords... seems like a weird backwards
requirement to only require it for gaining authorizations and not for
something like unlocking the screen.

[1] : See

http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00149.html
http://mail.gnome.org/archives/gtk-devel-list/2007-December/msg00169.html

> There has been some concern expressed about using PolicyKit with an RBAC
> backend.  If Solaris ships configuration files for both RBAC and
> PolicyKit, then users will likely need to understand and configure both
> systems to properly configure their setup.  There is a desire to avoid
> adding unnecessary complexity.  Perhaps a GUI that hides this complexity
> from the user could help to address this concern.

The only thing you need is to figure out whether an mechanism-defined
action (as defined in the .policy file shipping with the mechanism) is
allowed or not. So you would just have a small white-list for known
applications _if_ you don't want to trust the defaults provided by the
mechanism vendor.

I think the central problem here has to do with expectations and _who_
you are designing the OS for. Now, PolicyKit allows the mechanism vendor
to ship defaults - we need this because in modern desktop systems
intended for _consumers_ you (as the OS vendor) have zero control of
what is installed by default. Contrast this with the typical mind-set
where security/authorization framework designers happily assume they are
in full control of what is on the box and provide little or no way for
3rd party apps to participate. It just doesn't work in a modern desktop
operating system.


> Regarding RBAC, it has been a NIST standard since 1992.  Sun is just one
> company that implements RBAC, it is not a Sun technology.  

The NIST stuff, last time I checked, is more like a list of abstract
requirements that can apply to a ton of different systems (including
database systems where it is mostly used). Calling RBAC a standard is a
stretch, I mean, there's no well-defined API, file formats or anything. 

Again, PolicyKit is just an _interface_. You can implement almost any
kind of access control (both DAC and MAC) since PolicyKit provides a
wealth of information about what is going on and the actual decision
making happens in a separate trusted process.

The default authority implementation in PolicyKit (dubbed the Local
Authority) basically implements most of the useful bits of RBAC (as per
the NIST requirements). Other PolicyKit authority implementations may
implement other things; for example the Red Hat IPA team wants to
implement an authority that reads authorizations from a centralized
directory server.

       David