[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: setgid-wrapper

On Tue, 2004-05-18 at 09:03, Steven Augart wrote:
> Dear James,
> James Damour wrote:
> > On Mon, 2004-05-17 at 14:29, Steven Augart wrote:
> >>Grzegorz B. Prokopski wrote:
> >>>As for SGID - if this is java game, so you most probably have a shell
> >>>wrapper.  S[UG]ID bits do NOT work on shell scripts.[....]
> >>>What you probably could do is write a small C wrapper, 
> [...]
> >>I was thinking it might make sense to create a program (and package) named
> >>setgid-wrapper?   [....]
> [....]
> >>setregid() to (user's real group, games-group), setreuid() to the user's
> >>real id, and execute the real executable.
> [....]
> > Sadly, I don't think that this would help in my case.  The problem with
> > filler is that it is a Java application, so it's driver script invokes
> > the "java" command; more often than not, "java" is actually another
> > script that eventually (perhaps through a chain of several other
> > scripts) invokes an ELF.  Worse yet, the exact nature of the script
> > varies from installation to installation (i.e. it is different for
> > Sun/Blackdown Java, Kaffe, SableVM, and GCJ).
> Good point. Fortunately, at least in the case of "filler", it only 
> requires a small modification of the setgid-wrapper.
> As you probably know, when a shell sees that it is running a setuid or 
> setgid shell script, it detects this because the euid and ruid or egid 
> and rgid are different.  It "fixes" this by setting the euid to be the 
> same as the ruid, and/or egid the same as the rgid, effectively 
> turning off the setuid/setgid bit.

Actually, I didn't know that.  Thanks for the info!
> But, if the egid and rgid are the same, then the shell script leaves 
> them alone.  (Indeed, unless it's running as root, it has to leave 
> them alone -- it does not have permission to do anything else.)
> So, instead of setgid-wrapper calling setregid() to (user's real 
> group, "games"), it will have to call setregid to (games, games)
In this case, this setgid-wrapper concept would work for *all* Java
applications.  I'm still not sure if it will work for shell driven apps
in general, but it sounds reasonable.  Security may be a concern, but I
believe that a simple, well written setgid-wrapper program, that only
runs programs listed in its (root-owned) configuration file should be at
least as secure as cron or at.  We should be sure to borrow the
configuration update logic from cron or at to make sure that we are
modifying the file in a way that is both secure, and meets Debian
project guidelines.  

Should I take the first crack at writing setguid-wrapper?  Should we
pass the concept by Debian Security first?

> This will not pose any problems, *except* that any new files the 
> program creates will have their group set to "games" instead of to the 
> user's default group.

I think that this is actually the desired behavior.

> If you want to include debian-mentors in our correspondence, you 
> certainly have my permission to send this reply, or quotations from 
> it, to the list.

Roger.  Wilco.

James Damour (Suvarov454) <suvarov454@users.sourceforge.net>

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: