suid root "secure" chown, anyone?

suid root "secure" chown, anyone?

Post by Mike O'Conno » Sun, 29 Dec 1996 04:00:00



AIX doesn't appear to provide a configurable option to support people who
want SysV "users can chown" chown behavior rather than the POSIX "only
root can chown" behavior.  Is this really the case, or is there some sort
of rstchown setting like there is in Solaris and Unixware?

If not, has anyone implemented a suid root chown that users can "safely"
run?  I was thinking of hacking the GNU chown to do this, but I figured I
can't be the first person to have run into this problem before.  

--

"The world bores you when you're cool."                                -Calvin

 
 
 

suid root "secure" chown, anyone?

Post by Felix Schroet » Mon, 30 Dec 1996 04:00:00


Hello!


Quote:>AIX doesn't appear to provide a configurable option to support people who
>want SysV "users can chown" chown behavior rather than the POSIX "only
>root can chown" behavior.  Is this really the case, or is there some sort
>of rstchown setting like there is in Solaris and Unixware?
>If not, has anyone implemented a suid root chown that users can "safely"
>run?  I was thinking of hacking the GNU chown to do this, but I figured I
>can't be the first person to have run into this problem before.  

Note that by allowing users to give away files, you allow them to
circumvent disk quotas (if you have them). Additionally, you can run
into several potentially severe security problems, e.g. with at and cron.

Regards, Felix.

 
 
 

suid root "secure" chown, anyone?

Post by Mike O'Conno » Mon, 30 Dec 1996 04:00:00



:>If not, has anyone implemented a suid root chown that users can "safely"
:>run?  I was thinking of hacking the GNU chown to do this, but I figured I
:>can't be the first person to have run into this problem before.  
:
:Note that by allowing users to give away files, you allow them to
:circumvent disk quotas (if you have them). Additionally, you can run
:into several potentially severe security problems, e.g. with at and cron.

I'm aware of this.  The environment I need this for doesn't have disk
quotas, and I'm more concerned with these guys not accidentally blowing
up the OS with chown rather than doing something malicious.  I'm aware of
the security implications.  However, I need this functionality.  Others
provide it.  IBM doesn't.  A "reasonably secure" suid chown (something
more secure than just making the current chown binary suid root!) sounds
like my best bet, but I'd like to avoid reinventing the wheel.

--

"Never never never never never never NEVER trust a tiger."             -Calvin

 
 
 

suid root "secure" chown, anyone?

Post by Andrew Gier » Tue, 31 Dec 1996 04:00:00


 Julianne> The real problem is going to be closing the race conditions.

fstat() and fchown() are your friends :-)

That brings on another problem, though - you don't want to risk open() if
the target is not an ordinary file or directory, so a user-level chown
would probably have to forbid changing devices or fifos.

--

"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam

 
 
 

suid root "secure" chown, anyone?

Post by Casper H.S. D » Wed, 01 Jan 1997 04:00:00



>fstat() and fchown() are your friends :-)
>That brings on another problem, though - you don't want to risk open() if
>the target is not an ordinary file or directory, so a user-level chown
>would probably have to forbid changing devices or fifos.

Even fstat() and fchown() won't be of enough help, I think, to close
one final race condition.

Chown, when run as non-root user the set-uid/set-gid bits.
It doesn't change those bits when run as root (anyway, that may differ
from system to system, but you'd better check).

So you can't just open (O_NDELAY) and do fchown.
You'd need to fstat, remove set-uid set-gid bits and tehnm chown.

And that's where the race comes in;until after the chown, your
fchmod() can be undone by the current owner.

fchmod after the fchown will be too late, the exec can have been issued.

You'll need to get yourself an intermediate user which isn't allowed to
call you set-uid chown to be safe.

Casper
--
Casper Dik - Sun Microsystems - via my guest account at the University

Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

suid root "secure" chown, anyone?

Post by meem » Fri, 03 Jan 1997 04:00:00



Quote:> How do you do =that= reliably?

> If you assume that the open() is the evil system call, again, I can
> run off and play the same race game with the stat/open pair that I just
> played with stat/chown ...

if i understand what you're saying, you can solve the problem by doing
an open() and then fstat()'ing the returned descriptor.  then, if
things look like you "shouldn't have permission" you can close().

--

::   pgp fingerprint:   E7 E8 1A 95 F2 06 6A D6   6A 11 44 D6 6A 6B 93 9B   ::
:: GCS v3.12: a--- C+++ UL++++ US+++ UB+++ P++ L+++>++++++ E+>+++ W+ N++ K+ ::

 
 
 

suid root "secure" chown, anyone?

Post by Andrew Gier » Sun, 05 Jan 1997 04:00:00


 Julianne> The real problem is going to be closing the race
 Julianne> conditions.

 >>  fstat() and fchown() are your friends :-)
 >>
 >> That brings on another problem, though - you don't want to risk
 >> open() if the target is not an ordinary file or directory, so a
 >> user-level chown would probably have to forbid changing devices or
 >> fifos.

 Julianne> How do you do =that= reliably?

stat() before the open. The race condition in this case seems to be
harmless; the only attack would be to persuade the program to open (but not
alter in any way) a device or fifo not accessible to it but located in a
directory to which the attacker has write access (which would be a bigger
hole anyway).

I have occasionally wondered whether an O_NOACCESS option would have uses
(to go with O_RDONLY, O_WRONLY and O_RDWR) - the ability to open something
without actually *doing* anything to it, just to have a reference to it,
might sometimes be handy.

Since this question came up in relation to AIX, is it possible to avoid
all the race conditions and other problems by doing it in a kernel
extension?

--

"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam

 
 
 

suid root "secure" chown, anyone?

Post by Harrison Berger » Thu, 09 Jan 1997 04:00:00






 >>>AIX doesn't appear to provide a configurable option to support people who
 >>>want SysV "users can chown" chown behavior rather than the POSIX "only
 >>>root can chown" behavior.  Is this really the case, or is there some sort
 >>>of rstchown setting like there is in Solaris and Unixware?
 >>
 >>>If not, has anyone implemented a suid root chown that users can "safely"
 >>>run?  I was thinking of hacking the GNU chown to do this, but I figured I
 >>>can't be the first person to have run into this problem before.  
 >>
 >>Note that by allowing users to give away files, you allow them to
 >>circumvent disk quotas (if you have them). Additionally, you can run
 >>into several potentially severe security problems, e.g. with at and cron.
 >
        Put those people in the same group and just have them copy
        it. Then you build in a disk buffer too, as it will always
        look like there is less disk space than there is,due to
        duplicates that you could track down and delete, but since
        when the file is copied the original user will not have
        gained any space in the process, that user will probably
        want to delete them in a hurry all without encouragement.
        Since these people can would presumably be able to chown
        each others files you could play with directory permissions
        on their HOME directories. Make them 750. You might also
        get some creative mileage out of chgrp, since you can
        change the group if you own the file and are in the group.
        Note: This represents quite a large value for a binomial
        coefficient in the worst case scenario. You should be able
        to do something reasonable. If you can't trust your users
        somewhat, give them to microsoft.

--

    Steinberger:  
State of the Instrument  

 
 
 

suid root "secure" chown, anyone?

Post by Ing. Enrique Sanchez Ve » Thu, 16 Jan 1997 04:00:00


: If not, has anyone implemented a suid root chown that users can "safely"
: run?  I was thinking of hacking the GNU chown to do this, but I figured I
: can't be the first person to have run into this problem before.  

Mike,

   Use sudo this might be an overkill but it will work very nice.

best regards,

Enrique.

 
 
 

suid root "secure" chown, anyone?

Post by Doug Siebe » Fri, 17 Jan 1997 04:00:00




>: If not, has anyone implemented a suid root chown that users can "safely"
>: run?  I was thinking of hacking the GNU chown to do this, but I figured I
>: can't be the first person to have run into this problem before.  
>Mike,
>   Use sudo this might be an overkill but it will work very nice.

Not really.

sudo chown myname /etc/passwd
vi /etc/passwd

You'd need to wrap it to check for such nastiness (also check to make sure
you aren't making something owned by you and setuid owned by root or someone
else) but once you have wrapped it, you may as well be writing a proper
secure chown in the first place.

--
Douglas Siebert                Director of Computing Facilities

Ack!  My reality check just bounced!!