[ale] GTK error

Michael B. Trausch mike at trausch.us
Thu Jan 27 11:58:51 EST 2011


On Thu, 2011-01-27 at 11:37 -0500, Randy Ramsdell wrote:
> I don't get it. From the link, "You should not make your GUI setuid at
> all. Why run the risk of security bugs in code that does not need to
> be running with elevated privileges?" but what states that the 
> setuid/setgid user is an elevated user?

The only reason to write a program that is setuid or setgid is to confer
some additional privilege that the user does not (or rather, may not be
assumed to) have.  Perhaps the most well-known example of this is the
"passwd" program, which is setuid root so that it has the ability to
modify the user's password in the shadow database.

Honestly though, I have to disagree with the whole idea of having
programs that are directly invoked by any user being setuid.  I agree
with the text on the GTK setuid page: setuid programs should be run as
backends for non-setuid programs.  At least for all situations that I am
familiar with.  Sadly, PAM does not agree with me, nor does many of the
programs that I have seen that won't (or can't) operate without being
setuid.  It makes things pretty difficult to do in certain
circumstances.

Imagine what could be done if the simple task of authenticating to the
operating system did not itself require root privileges.  It's possible,
though it's not the way that we currently do things in Linux-land (or in
any other UNIX or UNIX-like system that uses PAM for authentication).
Imagine if there was an authentication dæmon and an authorization dæmon.
Then programs could be written with normal user privileges, and if they
need to perform an authenticated action, they can call some other
program that is much more limited and much more easily audited in order
to perform the privileged operation.  This is how PolicyKit works, if
I'm not mistaken.  It is also how BSD authentication works, if I am
again not mistaken.  This means that the code running as the user does
not directly handle things like creating partitions or filesystems, but
instead will call a program that is privileged in order to do those
things on behalf of the user that is logged in.

As an example, PolicyKit makes it possible to manage partitions and
filesystems using the Disk Utility that is distributed with Ubuntu.
Disk Utility doesn't directly call programs to make filesystems or
modify partitions; as I understand it, there is a helper backend that is
called (I think via DBUS, but I am not 100% certain of that).  The
helper backend has no user interface other than IPC.  PolicyKit handles
the authorization, and if the user is authorized to perform the given
action, then it will allow the front-end to connect to the back-end and
ask the back-end to perform the privileged operation.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110127/5cd68133/attachment.bin 


More information about the Ale mailing list