[ale] GTK error

[Jim Kinney]

With SELinux, /usr/bin/passwd is setuid 0 but /etc/shadow is set to
ONLY allow access from /usr/bin/passwd (actually it uses a
passwd_exec_t type). This splits off admin privileges from a user to a
process.

As a user normally is logged in, they are running a non-privileged
shell so that process is what calls the setuid passwd. That's what you
want in your discussion :-)

Most cases I've seen in modern linux, setuid is _very_ limited to only
writing to /etc/[g]shadow or a user-called process that touches the
hardware layer in a non-shared way. And most (if not all) of those are
pretty well gone (sound stuff may be a hold out).

On Thu, Jan 27, 2011 at 11:58 AM, Michael B. Trausch <mike at trausch.us> wrote:
> 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
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>



-- 
--
James P. Kinney III
I would rather stumble along in freedom than walk effortlessly in chains.