Re: [PATCH] set*uid() must not fail-and-return on OOM/rlimits

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

 



Alan Cox wrote:
Ar Llu, 2006-08-21 am 02:12 +0400, ysgrifennodd Solar Designer:
Are you referring to killing of processes on OOM?  That was in Linux
already, this patch does not introduce it.

(pedantic) Only if you have overcommit disabled.

As it relates to setuid() in particular, POSIX.1-2001 says:

     The setuid() function shall fail, return -1, and set errno to the
     corresponding value if one or more of the following are true:

     [EINVAL]
             The value of the uid argument is invalid and not supported by
             the implementation.
     [EPERM]                                                                                 The process does not have appropriate privileges and uid does
             not match the real user ID or the saved set-user-ID.

No other error conditions are defined.

I'd say that the behavior of returning EAGAIN is non-compliant.

You are allowed to return other errors. What you must not do is return a
different error for the description described in the text as I
understand it.

But the kills are needed.  They are more correct and safer than
returning EAGAIN.  An alternative would be to not allocate memory on
set*uid() at all - like we did not in older kernels - but that would
be an inappropriate behavior change for 2.4.

It is certainly an awkward case to get right when setuid code is not
being audited but I still think you are chasing the symptom, and its not
symptom of crap code, so you are not likely to "fix" security. A lot of
BSD code for example doesn't check malloc returns but you don't want an
auto-kill if mmap fails ?

The kill has the advantage that it stops the situation but it may also
be that you kill a program which can handle the case and you create a
new DoS attack (eg against a daemon switching to your uid). The current
situation is not good, the updated situation could be far worse.

The message is important, we want to know it happened in the memory
shortage case anyway.

How about going ahead with the uid change (if the current user is root) BUT still return -EAGAIN. That way programs that ignore the return value will at least no longer have root privileges.

Peter
--
Peter Williams                                   [email protected]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux