arla-0.38

[Alexander Boström]

tis 2004-12-28 klockan 12:38 -0500 skrev Jack Neely: 
> On Sun, Dec 26, 2004 at 02:32:00AM +0100, Love wrote:
> > 
> > * Enables PAGs without setgroups() override on Linux 2.6
> > 
> 
> Whoa...how does this work?

It is exactly that, group-based PAGs as usual, but without the
setgroups() override.

First of all, remember that any PAG that is used by a process is
available to any other process with the same uid, if the code explicitly
uses ptrace() to "borrow" it. This is true even with the override in
place, of course.

However, without the override, a process that calls setgroups() will
accidentally end up with the wrong PAG (a default PAG). Although I'm not
aware of any such case (except su), to be safe you should not put tokens
in the default PAG of root or any other user if there *might* be some
setuid root binary that calls setgroups() and switches to the uid of
that user.

But you shouldn't put tokens in the default PAGs of such special users
even with the override in place, because changing uid is still enough to
switch PAG if a process doesn't have a PAG group. So disabling the
override really doesn't change anything in that respect, unless all
untrusted processes always have a PAG group attached to them.

su should be safe, since it does proper authentication. Regarding PAGs,
su will behave like if you were using the default PAG. (Always use the
default PAG of the target user or whatever PAG was allocated by a PAM
module.) Different, perhaps confusing, but not really a problem.

So, in short: If users always get a PAG allocated for them when they log
in, and the sysadmin kinits in the default PAG of root, then this might
be a problem. If users sometimes run without a PAG group, and the
sysadmin kinits in the default PAG of root, then the potential problem
already existed, even with the override in place.

/abo