Re: analysis: securelevels vs securebits with capabilities

Domas Mituzas (midom@dammit.lt)
Wed, 23 Jun 1999 17:20:47 +0200 (CEST)


Hello,
> IMHO : they should just do what they want and check for errors like
> EPERM .
>
> No need for trying to be "smart" and simulate the result that the kernel
> will give you anyway ( and it will be correct too :-)

That is what I changed in those "smart" applications... It checks for
errors after setuid/setgid/bind etc. That is fault of poor software
designers, who think, that (uid_t)0 is everything. The same can be with
securelevels. When you raise them, certain actions are disabled, and there
still are programs that think they are super-programs as they are ran with
uid 0.

A lot of software should be rewritten. But there are several problems:

1. file system capabilities need special patch of Andrew Morgan and
special module - still file system drivers do not support capabilities.
(present driver is still enough, but it keeps all capabilities in RAM - it
has both pluses and minuses. pluses for fast access and auditing - it has
a file in /proc, where all capabilized programs are listed, minuses - it
uses ram :)

2. task-level capabilities are enabled in Linux kernel 2.2, but one
capability is still disabled (it's easy to enable :) - that is cap_setpcap
- capability to set capabilities :))) I got stuck when I met this thing
for the first time, but it was easy enough to enable it in capability.h.

3. where is documentation? I started writing my own howto, but I don't
think it will be broad enough to be called a howto. Andrew Morgan has
written some documentation for linux-privs project. I found it rather
usefull, but it didn't explain properly (or I missed) about implementing
caps in Linux system.

Securelevels were also not documented properly, but what they gave was
simple enough both for users and developers. Capabilities can be called as
an enhancement to system, that should be described in lpg or somewhere
else :-) With equal rights as setuid() and setgid()....

With respect,
Domas Mituzas

-
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/