David:
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.
I heard from Lin Guo at Sun that he has followed up and sent an email
to devkit-devel about our plans. He works on the team at Sun which is
responsible for HAL, PolicyKit, and DeviceKit; so I hope this starts a
better dialog between Sun and the upstream community.
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.
Right. I was not trying to suggest that this is necessarily a blocker
for integrating PolicyKit in Solaris. Trusted path is particularly
important in the Trusted Solaris product. Until the above work is done,
PolicyKit could, I am sure, be configured to do the right thing (e.g.
never pop up dialogs asking for passwords) in this environment. The
fact that PolicyKit doesn't "just work" with Trusted Path today just
makes the process of integrating it into Solaris and making sure it is
configured properly in various environments, such as Trusted Solaris,
more complicated.
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.
Jon McCann gave a presentation at the 2007 GUADEC that he was interested
in making GDM manage the screen lock dialog in a separate VT, to better
address lock screen trusted path issues. I do not think much work has
been done on this yet, but it does not sound too impossible.
If that work is done, perhaps the GDM interfaces could be further
extended so that programs like PolicyKit could call GDM to trigger
a similar authentication dialog. Thus making GDM a single-point program
to manage authentication dialogs in a secure, trusted path manner.
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.
As I mentioned above, for Sun trusted path is more of a concern with
Trusted Solaris. The Trusted Solaris product locks down the user
environment so that users cannot do things like starting up a terminal
to run ssh or su, where they might enter a password.
Today in Solaris/OpenSolaris, the lock screen does not run in the
Trusted Path, unless you are using Trusted Solaris. Trusted Solaris
makes use of an Xserver extension written by Sun (not too dissimilar to
SELinux) that forces the screen lock to run in the trusted path. One
problem with this approach is that the lock screen is not accessible
when using Trusted Solaris.
Ideally it would be better to move away from this solution and use a
lock screen solution that "just worked" with trusted path without
hacking around with Xserver extensions. For example, if GDM managed the
lock screen and provided a11y similarly as it does today for login, then
this would work better and would provide a more secure trusted path
environment for all users.
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.
Right, I also was not trying to suggest that this is a blocker for
integrating PolicyKit into Solaris. I think the issue, as you say, is
more about figuring out the right PolicyKit <-> RBAC mappings, and
figuring out the right defaults for various typical Solaris/OpenSolaris
environments (e.g. Trusted Solaris, Sun Ray, etc.). I think this will
be a significant amount of work.
While I understand that PolicyKit supports the ability to support a
Solaris RBAC backend, the fact that RBAC and PolicyKit have their own
separate configuration files does make things significantly more
complicated. Coming up with the best way to integrate PolicyKit into
Solaris to mitigate this complexity, as much as possible, will also be a
challenge, I think.
As I mentioned before, Solaris does ship PolicyKit, but it is currently
only used by a few specific things, such as HAL, the power manager, and
I believe it will be used by Sun's DeviceKit. It wouldn't surprise me
if Sun makes PolicyKit more widely available in the future, but there
are some complicated issues that will need to be sorted, obviously.
Brian
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
