Here we came to discussion of people, who used securelevels and ones who
used capabilities (or read about them). imho this should be analysed more
in order to decide which thing should be developed. I was not the author
of both things or any of them, but I tried to analyse, and in some cases
to develop them.
What do they mean:
Securelevels disable a set of functions in OS. It is impossible to select
which ones to disable or enable. It is system-wide setting, that is
mandatory for whole system.
Securebits have something similiar to securelevels - they are also
system-wide, but blocking of functions is given to capabilities mechanism.
Capabilities - _task_ level limits (or privileges) that enable or disable
certain functions for task (process).
How to set them?
Securelevels can be set up by pid #1 to say 1 into certain file in /proc.
Or by patching kernel to add a new syscall for setting securelevels. Or by
writing utils, that change securelevels via /dev/kmem (method, I was using
for my tests, the util that was written by my friend [greetz swoop =]).
The same way as for securelevels should be applied to securebits... Still
there is no such syscall or any other ability swiftly to set it. I used
the same utility :)
And the most pleasant work is with capabilities. They have normal syscalls
and normal libraries (libcap - check this out at ftp.*.kernel.org/pub/linux/
libs/security/linux-privs/). The global restrictions still should be set
up in include/linux/capability.h file. It is difficult to compare the
effective/inherited/permitted capabilities with things we have in
securelevels, as theese two methods are working in different levels. It is
possible to set capabilities for a running process via syscall. Also
programs can lower their capabilities to what they require. The best way
for me was using file system capabilities - they are given to an inode.
Then the program on that inode is executed, it gets capabilities it needs.
So still we see, that capabilities are more flexible.
What do we achieve?
Securelevels bring the system in halfly configurable mode. It is
impossible to change anything with immutable or append only files.
Impossible to listen on raw network sockets. But still possible setuid(),
setgid(), root is still superuser, that can override access lists. still
network interfaces can be configured. etc. So, by setting securelevels you
bring your system to one state. But you don't have, what you need for that
task...
Capabilities set the system to any mode you like. You can run ping, that
is nonsuid, if it has cap_net_raw capability. You can make fwadmin user,
who can start ipchains while not running as root - there is special
capability for firewall management. You may allow or disallow listening
on raw sockets, setuiding or setgiding. And - you can make it in task
level, so mail server will be still easily setuiding in order to safely
deliver mail, but users won't be able to change their ids. Any operation,
that requires root can be substituted with one, that uses capabilities. As
a summary root user is a user, who has all capabilities set on.
And securebits (secure_noroot) - they just remove all capabilities from
uid(0).
SUMMARY (about capabilities)
It may sound non-unix'ish, but it's cool. It may be future of unix
systems, not only mainframes =] What it needs - a little bit better
software design (in many applications I found {if (getuid()!=0) DIE("!");}
so they should be rewritten to check if they are capable to do their job.
Here are some capabilities I use on my system:
cap_net_raw=ei /bin/ping
cap_net_raw=ei /usr/sbin/traceroute
ping and traceroute require raw network access. I gave them. They do not
require root any more :-)
cap_dac_read_search,cap_setgid,cap_setuid+ei /bin/su
dac_read_search - I want to let /bin/su to read /etc/shadow. And no more.
cap_setuid, cap_setgid - for direct su job :-)
cap_dac_read_search,cap_setuid,cap_setgid,cap_fowner,cap_net_bind_service=ei
/usr/sbin/sshd1
dac_read_search - for reading /etc/shadow :-) setuid, setgid - for setting
user ids. fowner - to change owners of ttys. net_bind_interface - to
listen on 22'nd port.
It is not so difficult to enhance applications to use theese methods. Now
what we need it proper development and standards of theese capabilities =]
If anyone still finds, that securelevels are better - say it :)
With respect,
Domas Mituzas
17teen year old gymnasium student :-p
-
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/