[I'll only show you bugs in this mail...]
> Calling process: ( I feel certain this can be easily arranged with the
> 'stickable' solution, and don't want to make this example longer than it
> already is)
> uid=named
> gid=named (only)
> permitted bits=0
> inheritable bits=0
> effective bits=0
>
> Named binary:
> -rwsr-x--T 1 named named 432880 Jan 4 01:07 named*
Why is it suid named? Suid means you have all privileges you had
before _PLUS_ that of named.
> permitted bits=CAP_NET_BIND_SERVICE (only)
> inheritable bits=0
> effective bits=CAP_NET_BIND_SERVICE
> extended file attributes=immutable bit set
>
> named process after exec'ed by calling process: (CAP_NET_BIND_SERVICE
> abbrev. to CAP_NET)
What is uid of calling process? If it is not named, you have more
privileges than you think. Aha, you said calling uid is named. Why is
it suid, then?
> uid=named
[BTW There are 4 different uids. In case your named is executed by user
pavel, named has euid = named, ruid = pavel and can choose any of
these two.]
> bash binary:
> -r-xr-xr-T 1 root root 426980 Oct 19 22:57 bash*
~ hmm, your bash is not executable by normal user, only
group root? Strange.
> Now, let's say another remotely-exploitable buffer overflow is found in
> named(8). A black hat overflows the buffer, and manages to exec a bash
> shell. Now let's compute the state of the bash shell that's been
> exec'ed:
> bash shell process running parameters:
> uid=named; rights in fs: read rights only to: /etc/named.conf,
> /var/named/*, and /usr/sbin/named; write rights to
> /var/named/(secondaries); execute right to /usr/sbin/named
You forget a few: r/w access to /tmp, r/o access to rest of
filesystem.
> So after the attack, the attacker is left only with a shell that can:
> - trash /var/named/(secondaries)
> - re-start named(8), but not modify it in any way.
>
> Which, IMHO, is about as secure as you can get. (dunno for sure if it
> can't be improved)
Assuming attacker needs to do exec. Which is NOT true.
> Now, I see three situations possible with setuid0:
> 1) you can mark named(8) setuid root and implement exactly my scenario
> above. I hope you reject the idea of setuid root named as fast as I
> do.
I'd use
rwxr-xr-x root root named*
, with capability headers, saying
permitted bits=CAP_NET_BIND_SERVICE (only)
inheritable bits=0
effective bits=CAP_NET_BIND_SERVICE
I do not need to mark named suid root. In this case, capability
headers are only _dropping_ privileges, and I need no suid root to do
that. So I can do your scenario without marking it suid root. [I
believe that you do not need to mark your executable sticky, btw.]
Aha, I'd need calling process have CAP_NET, and to change its uid to
named's before executing me. As calling process is expected to be
init, for me, it is uid=0 and all capabilities, so it is going to have
_also_ CAP_NET, and can change its uid easilly.
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- 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/