Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Kernel Security Features In 2.4 Explained

Posted by timothy on from the hey-you-can't-do-that!-bang-bang dept.

bewmIES writes: "Dave Wreski of linuxsecurity.com and author of the recent netfilter article here on slashdot has written an excellent introduction to some of the latest security enhancements to the 2.4 kernel entitled Linux 2.4: Next Generation Kernel Security. He speaks about the future of crypto integration, new character and block devices, and has a very well-written summary of capabilities." Perhaps this will answer at least some people's needs for ACL capabilities in Linux.

2 of 98 comments (clear)

  1. A KISS alternative to capabilities by Ignatius · · Score: 5
    Why not take the same approach to capabilities as it is done with devices: Standard UNIX permissions already allow any arbitrary combination of access rights to character and block-devices to be granted to users and (via. the SUID flag) also to programs.

    To extend this scheme to privileged system calls, simply make up some pseudo file (e.g. /proc/cap/settimeofday) and let the kernel check the permissions of these files against the uid of the calling process.

    To implement capabilities, just make a new group for each pseudo-file (perm. 660), create a user for the privileged executable and make him a member of the necessary capability groups.

    To stick with the xntpd example from the article:

    -rwsr-x--- ntp admin /usr/bin/xntpd
    -rw-rw---- root settime /proc/cap/settimeofday
    -rw-rw---- root deamon /proc/cap/privport

    while user "ntp" is member of the "settime" and "deamon". Any member of the "admin" group can then start xntpd, which then runs under SUID "ntp" and has only the necessary privileges to serve its supposed purpose.

    Such an approach would have a number of advantages:
    • No recompiles of userland programms necessary.
    • Consitent with the existing permission scheme for device drivers.
    • Can be applied to users as well as programms.
    • Privileges can be revoked at any time without having to rely on proper behaviour of the program (e.g. gobally drop permissions to open privileged ports after boot-up phase)
    • No new userland tools necessary.
    • No extra process data structures in the kernel.
    • Dosn't require any new filesystem features.
    • Probably a lot easier to implement.
    • Just give all capability files perm 600 root.root and you have everything as it is now.

    I'm sure that people more familiar with security systems will come up with an equally long list of drawbacks (lower flexibility in changing permissions dynamically or dropping privileges after startup comes to mind), I think, however, that the above scheme could solve a good deal of the existing problems without introducing too much new complexity.
  2. Neat idea, but ... by ip4noman · · Score: 5

    The "capabilities" are a neat idea, but it is the honor system. Applications need to be written to relinquish the privs they don't need. Legacy apps will *still* have God privs...

    Quite powerful. At the same time, it's also contains a certain potential danger due to making an unprivileged binary slightly privileged.
    System admins take note. No longer will you simply need to "find / -user root -perm -4000" to locate privledged programs. Introduces a new mechanism for hax0rz to hide things ...