Messages in this thread | | | Date | Tue, 22 Jun 1999 21:18:16 +0200 (CEST) | From | Domas Mituzas <> | Subject | analysis: securelevels vs securebits with capabilities |
| |
Hello, gurus :-)
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/
| |