In <200002122227.XAA22705@cave.bitwizard.nl> Rogier Wolff (R.E.Wolff@BitWizard.nl) wrote:
> 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_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.
IF passwords are there :-) Not always the case. They can be on other system
for example (and no, NIS with a lot of holes is not the only way to do this).
> #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.
If you had nfs and/or rsh your system was improperly configured to begin with.
> #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?
Since you are not using ssh or lsh you had problem from the very beginning.
> Need I go on?
Most capabilities can be exploted when system was already not very
secure. If you have two locks on door and so happen that YOU do not use
one of them it does not mean that the only protection is remaining lock:
someone can have other lock locked ! Yes, each capability has some value
(that's why they are not allowed for "normal" user to begin with) but
to say that each and every one can lead to root is VERY misleading. In
YOUR system -- may be. Not in EVERY system.
> 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.
Only if there EXIST root on system :-) Once capabilites support added to
filesystem we can remove root (as superuser that is) from system.
> 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.
This road looks straight ONLY since you not tried to make it harder. NFS and
rsh are just plain invitations for intruders for example. Systems can be
designed differently and only few basic capabilities can be exploited in
ALL systems.
-
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:25 EST