documentation:rsbac_handbook:security_models:cap
=>  Releases

Current version
Git/Latestdiff: 1.5.6

Latest Snapshots
Produced after each commit or rebase to new upstream version

GIT
RSBAC source code, can be unstable sometimes

=>  Events

No events planned

Linux Capabilities (CAP)

This module can be used to

  • restrict rights of programs run by root
  • add root rights to normal users or programs run by them

It is only the RSBAC module which directly interferes with existing Linux access control.

Warning: The standard Linux ld.so dynamic linker does not know about min_cap settings, so it is possible to attack programs with min_caps settings with libraries in LD_PRELOAD! You should make sure that such programs are always started from a controlled environment, e.g. a wrapper cleaning the environment before starting the program!

How it works

On each setuid and execute, the CAP module first removes the capabilities not in the maximum set and then sets the given minimum caps. The values changed are the standard Linux capability values in the process task struct. This means that the RSBAC CAP module (like PAX and RES) is only an administration helper for existing Linux settings. Shortly said: final set = (original & max_caps) | min_caps.

All capability based decisions are done by original kernel code, which does not log anything. This is why you will never see a log message for missing capabilities, unless you enable specific CAP logging (from v1.2.4). Else, access will just be denied.

In softmode, the CAP module only enforces the minimum, but not the maximum values - this is the closest to the softmode idea it can get. If you start a daemon with a reduced maximum capability set in softmode, you should make sure to restart it after switching to secure mode - otherwise it will have unwanted capabilities.

If something works in softmode, but not in secure mode, you should always suspect missing CAP maximum values or turn on missing CAP logging.

CAP is especially useful for administrators on the RSBAC system, who are not root, but need read access to all directories so that they can administrate there despite having insufficient Linux access modes.

Note: If you only want to partially disable Linux access control for filesystem objects for all users, you might consider to use the generic RSBAC functionality provided for this purpose through the “Allow disabling of Linux filesystem access control” kernel configuration option.

Starting with your CAP policy

Configuration is done easily thanks to the global learning mode added from 1.4.2 version. This global learning mode will allow you to create a least privilege policy faster and easier.

To start using learning mode just compile your favorite rsbac kernel with CONFIG_RSBAC_CAP_LEARN activated.

Learning mode works adding missing max_caps to the bound, so you could after resetting all binaries max_caps to 0 in softmode (softmode because system could be something like unusable if not), reboot in enforced mode adding rsbac_cap_learn parameter to your boot loader to make RSBAC system start learning. It is better to make and intensive use of your system after that to allow him to learn everything needed.

Something like this would help you with this task, this will make your binaries in /bin/ to have max_caps set to 0 (could be done better testing and excluding scripts but as example is enough):

for file in /bin/*; do attr_set_file_dir FD “$file” max_caps UA; done

Repeat with all directories where your binaries are, and you have done!.

If you will make use of minimal caps (for example to allow some user to use mount) it's wise to filter LD environment variables. RSBAC can do this for you. just make:

attr_set_file_dir FD /bin/ping cap_ld_env 0

And now if you granted ping NET_RAW as minimal capability, nobody could trick with it preloading libraries. Changing cap_ld_env to 1 allows them.



Table of Contents: RSBAC Handbook
Back: Security Models

//
documentation/rsbac_handbook/security_models/cap.txt · Last modified: 2013/08/26 18:22 by 127.0.0.1

documentation/rsbac_handbook/security_models/cap.txt · Last modified: 2013/08/26 18:22 by 127.0.0.1
This website is kindly hosted by m-privacy