Ion Badulescu writes:
> In article <cs.lists.linux-kernel/38F626F4.63102FBB@transmeta.com> you wrote:
>> On a similar note, I notice that recent versions of RedHat (via GNOME?)
>> seems to magically change owners on a whole bunch of devices. It seems
>> to me that it would be a *much* cleaner solution would be to have a
>> special group for the console owner, and when logging in the user add
>> that group to his auxilliary group list via setgroups().
>
> No, that would be a security problem -- and it's actually documented in
> the pam_group module documentation. If I, as the console user, become
> even temporarily a member of the console group, nothing prevents me from
> creating a setgid binary which will give me the group membership later,
> when I'm not on the console anymore.
This can be fixed in many ways. The most obvious (and dumb?) way
would be to let the admin specify a list of GIDs that the kernel
should restrict. Then the setgid binary either can not be created
or, once created, can not be used.
It may be better to give group IDs flag bits. One could get
Netware-style trustees almost for free by using a flag bit to
distinguish UID and GID values. Other flag bits could specify:
can setgid(), can chown(), can gain access, can lose access,
can use for killing processes, etc.
> The chown-ing on console login (or some similar method
> through devfs/devfsd) is the cleanest way to do this.
If that is the cleanest way, I'd hate to see the less clean ways.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:25 EST