Re: Someone help me understand this...?

> On Wed, 27 Aug 2003, Joe Greco wrote:
> > The specific OS below is 5.1-RELEASE but apparently this happens on 4.8
> > as well. 
> 
> Could you confim this happens with 4.8?  The access control checks there
> are substantially different, and I wouldn't expect the behavior you're
> seeing on 4.8...

Rather difficult.  I'll see if the client will let me trash a production
system, but usually people don't like $40K servers handing out a few
hundred megabits of traffic going out of service.  We were trying to fix
it on the scratch box (which happens to have 5.1R on it) and then were
going to see how it fared on the production systems.

> The man page definitely needs to be updated, but I think it's worth having
> a conversation about whether the current behavior is too conservative
> first...
> 
> These changes come in response to a class of application vulnerabilities
> relating to the delivery of "unexpected signals".  The reason the process
> in question is being treated as special from an access control perspective
> is that it has undergone a credential change, resulting in the setting of
> the process P_SUGID bit.  This bit remains set even if the remaining
> credentials of the process appear "normal" -- i.e., even if ruid==euid,
> rgid==egid, and can only be reset by calling execve() on a "normal" 
> binary, which is considered sufficient to flush the state of the process. 
> 
> These processes are given special protection properties because they
> almost always have cached access to memory or resources acquired using the
> original credential.  For example, the process accesses the password file
> while holding root privilege, which means that the process may well have
> password hashes in memory from its reading the shadow password file -- in
> fact, it likely even have a file descriptor to the shadow password file
> still open.  The same P_SUGID flag is used to prevent against unprivileged
> debugging of applications that have changed credentials and now appear
> "normal".  P_SUGID is also used to determine the results of the
> issetugid() system call, which is used by many libraries to see if they
> are running with (or have run with)  privilege and need to behave in a
> more conservative manner. 

Okay, well, that makes good sense.

> I don't remember the details, but there have been at least a couple of
> demonstrated exploits of vulnerable applications using signals in which
> setuid applications rely on certain signals (such as SIGALRM, SIGIO,
> SIGURG) only being delivered as a result of system calls that set up
> timers, IO, etc. I seem to recall it might have involved a setuid
> application such as sendmail on OpenBSD, but I'll have to do some googling
> and get back to you.  These protections probably fall into the same class
> of conservative behavior as our preventing setuid programs from being
> started with closed stdin/stdout/stderr descriptors.
> 
> Giving up privilege without performing an exec() is very difficult in
> UNIX, unfortunately, since the trappings of privilege may be maintained by
> libraries, etc, without the knowledge of application writers.  Right now,
> signal delivery in 5.x is pretty conservative if a process has changed
> credentials, to protect against tampering with a class of applications
> that has, historically, been vulnerable to a broad variety of exploits. 
> I've attached an (untested) patch that makes this behavior run-time
> configuration using a sysctl -- when the sysctl is disabled, special-case
> handling for P_SUGID processes is disabled.  I believe that this will
> cause the problem you're experiencing in 5.x to go away -- please let me
> know.

Well, I'm hoping more for a general fix for Diablo, rather than a special
patch for the OS.

> Clearly, unbreaking applications like Diablo by default is desirable.  At
> least OpenBSD has similar protections to these turned on by default, and
> possibly other systems as well.  As 5.x sees more broad use, we may well
> bump into other cases where applications have similar behavior: they rely
> on no special protections once they've given up privilege.  I wonder if
> Diablo can run unmodified on OpenBSD; it could be they don't include
> SIGALRM on the list of "protect against" signals, or it could be that they
> modify Diablo for their environment to use an alternative signaling
> mechanism.  Another alternative to this patch would simply be to add
> SIGARLM to the list of acceptable signals to deliver in the
> privilege-change case.

I wonder if it would be reasonable to have some sort of interface that
allowed a program to tell FreeBSD not to set this flag...  if not, at least
if there was a sysctl, code could be added so that the daemon checked the
flag when starting and errored out if it wasn't set.

> BTW, it's worth noting that the mechanism Diablo is using to give up
> privilege actually does retain some "privileges" -- it doesn't, for
> example, synchronize its resource limits with those of the user it is
> switching to, so it retains the starting resource limits (likely those of
> the root account). 

That's actually preferred in most cases.  News servers almost always eat
far more resources than whatever limits you might set by default, which
just turns into telling people to remove the limits or use root's limits.
Generally if a news package bumps limits bad things happen.

> A preferred structuring of privilege separation
> attempts to avoid this scenario by containing privilege in a process that
> is as independent as possible from the unprivileged processes, and uses
> file descriptor passing to get a bound port to the unprivileged processes,
> rather than credential manipulation which is fairly failure-prone.  

Yes, and such a thing is actually available, though it introduces some new
issues, because the daemons can be configured to allow various bound ports
(needing a variable number of fd's, etc) and this also breaks legacy sites 
where people have custom startup scripts.  Ugh.  We did that originally so
people could get core dumps on FreeBSD.

> Also,
> regardless of whether the outcome seems likely, it would be a good idea
> for Diablo to check the return values of the setuid/setgid/... calls and
> make sure they succeed.

Yeah, yeah, it's Matt Dillon legacy code.  Matt tended to ignore error
returns from things where an error was not expected and even if one was
reported, nothing (beyond a message) could be done.  It actually took me
a while to isolate the kill issue as a result, because...  the rval from
kill was being ignored (now the error gets syslog'ed).

Sigh!

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.