> Hi!
>
> [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.
uid 'named' has write rights to /var/named/(secondaries); the admin user
in a capabilities-based system design should probably not own any files.
>
> > 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?
In case admin fires it up by hand, so it can still write to it's
secondaries files.
> > 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.
Oops... typo on my part.
>
> > 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
So anybody who breaks uid=0 can modify the file's inheritable set to
inherit everything, and no CAP_SETFCAP is required. That's wrong.
> 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.]
Yes, I do need to mark it as capability enabled, because setting caps in
the fs (permitted -or- inheritable) is a priviledged op.
> 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.
What's worse here is the inheritable set; if admin exec's named by hand,
it gets a full inheritable set! That could be bad, which is why I'm also
suggesting addition of an fM, inheritable Mask. This would apply
inheritable for pP purposes, but also then drop most of pI. So the new
formula for pI would be pI' = pI && fM. With this, it would be safe for
an admin bash shell with a full inheritable set to exec named, and not
worry that named could then run a bash shell which inherits all.
cheers,
David
- --
David L. Parsley
Network Specialist
City of Salem Schools
-
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/