Horst von Brand wrote:
> R.E.Wolff@BitWizard.nl (Rogier Wolff) said:
> > Theodore Y. Ts'o wrote:
>
> [...]
>
> > > Don't be so sure it won't be a configuration/maintenance problem. You
> > > still have at least an order of magnitude more bits to manage, and the
> > > traditional tools for scanning for setuid bits won't work anymore. If a
> > > cracker installs a trojan shell which has the FS_DAC_OVERRIDE capability
> > > bit, "ls -l" won't show it as a dangerous program. Neither will
> > > "find / -perm +6000 -print".
>
> > Well, I don't know the actual incantation, but you shouldn't scan for
> > setuid programs on a capability based system.
>
> Yep. find(1) needs to be capability, ACL, whatnot, aware.
>
> > By the way, any almost any capability on a capability based system can
> > be leveraged to "root" (whatever that gives you).
>
> Examples, please? It is assumed that a correctly set up capability system
> avoids exactly this. Besides, "root" may well be just a random user name in
> that case.
#define CAP_DAC_OVERRIDE 1
Hmm. That one is obvious right?
cp /bin/sh /tmp
chown root /tmp/sh
chmod 4755 /tmp/sh
#define CAP_DAC_READ_SEARCH 2
Hmm. OK, I can now read any file on the system. Read /etc/shadown,
crack passwords from there. SOrry, there isn't any quicker way.
#define CAP_FOWNER 3
Hmm. I now "own" /etc/ password?
#define CAP_FSETID 4
Hmm. Something similar to:
cp /bin/sh /tmp
chown root /tmp/sh
chmod 4755 /tmp/sh
But now the chown won't work, so I'll ahve to work from a file that
happens to be root-owned already.
#define CAP_KILL 5
Hmm. Nasty DOS. Turn on debugging on various servers etc etc. Ok. Maybe
I can't become "root" immediately.
#define CAP_SETGID 6
Hmm. Go to any group (e.g. "disk" or "ppp" and do funky stuff!).
#define CAP_SETUID 7
setuid (0,0)
#define CAP_SETPCAP 8
Hmm I can't ADD to my permitted set. Too bad.
#define CAP_LINUX_IMMUTABLE 9
OK. I can't become root with this. But I can cover my tracks
which I shouldn't be able to do.
#define CAP_NET_BIND_SERVICE 10
- Bind to the portmapper, distract clients to my own nfs server.
have clients to nasty things (to make me root)
- rsh into local machine with false credentials.
#define CAP_NET_BROADCAST 11
Hmm. No, maybe not a route to "root".
#define CAP_NET_ADMIN 12
Mjam. Ifconfig an interface to an IP of a trusted host. Dump
packets on the net until I see "root" login?
Need I go on?
Many have a route to "root". The things you normally restrict to
"root" have that status, because they are dangerous to the local
machine. Someone smart will be able to leverage it to "root" (or full
capabilities) pretty easily.
And being "root", you suddenly own lots of files on the
filesystem. This means that you can modify for example the
"bootfiles", to give access (full capabilities) to some program, or
uid.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- 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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:23 EST