Home
News
Documentation
Access Domains in a nutshell
Installation Guide
LinSec userspace tools
Known bugs
Authors
Access Domains in a nutshell
Aims of the document
After reading this document the reader should be familiar with the concept of the LinSec filesystem access domains and how to configure them.
What are LinSec filesystem access domains
Remmember chroot? LinSec filesystem access domain defines, for each process, a portion of the filesystem it can use. To make the things a bit more complicated each process has read only filesystem access domain and read write access domain. Obviously, portions of the filesystem that are in process’ r-w access domain can be both read and written by the process while the read only filesystem access domain can only be read.
For example, you can define that pine can read and write mail spool dir and read lib dir and its configuration files. Thus, no exploit for pine can endanger lib dir and configuration file, just the mail spool for the respective user.
Where do the process filesystem access domains come from?
The contents of a process’ filesystem access domain is computed from:
- Executed binary’s filesystem access domain,
- Executing user’s filesystem access domain, and
- Parent process’ filesystem access domain.
The resulting new process’ filesystem access domain is a sum of the above listed filesystem access domains. For example, asssume vi editor has r-o filesystem access domains covering necessary libs and its configuration files. Then assume user foo has r-w filesystem access domain containing its home dir. Finally, assume shell has r-o access domain covering config files, and libs and also has r-w access domain containing /tmp. Now, when user foo starts vi from its shell the resulting process (vi) will have r-o access to its own libs and config files, shell’s config files and libs but it will also have r-w access domain covering foo’s home and /tmp.
There are two cases when parent process’ filesystem access domain is not inherited. First one is when setuid is performed, eg. login has some access domain but when user foo logs in (login suids to its foo’s uid and executes shell) foo’s shell will not inherit login’s fs access domain. Second one is if access domain elements are marked NON INHERITABLE (a bit about this later on).
How are access domains configured?
Filesystem access domains are configured using adadm tool which provides extensive help on syntax & semantics. Generaly, filesystem access domains are configured in terms of fs access domains groups. Each filesystem access domain group contains elements which can be either files or directories. With each of the elements a flag is associated. Flags can be one of the following:
- NONE – no flag 🙂
- NINH – non inheritable, ie the element will not be inherited by any children.
- EXCL – exclusion (shall be explained in the following section)
- BOTH – EXCL & NINH
Once filesystem access domain group is created members can be designated. Binary executable can be either a r-w member of a group in which case all elements of the group shall be accessible to the program in r-w mode or the it can be r-o member in which case it will only be allowed to read the group elements. Every binary can be a member of one or more fs access domain groups.
Access domain groups 0 and 1 have a special meaning. They are both default fs access domain groups ie. once created during the setup phase they may not be ever deleted. All executables are automaticaly members of both groups without explicit configuration. Access domain group 0 is default r-w group meaning that all executables shall be allowed to both read and write elements of the group. Access domain group 1 is default r-o group.
Users can be members of fs access domain groups in a similar fashion to executables. Furthermore, users can have separate fs access domain elements in their r-w fs access domain. This feature is required as every user shall need to access its own home dir, mail spool file etc. As these are different for most of the users they have to be defined for every user separately. Unlike for the capabilities model in which users that have no explicit LinSec structures created for them are assigned default uP and uB values, every user has to have LinSec fs access domain structure explicitly created. Furthermore, if the structure does not contain at least user’s home the user will not be able to login at all!
Example fs access domain configuration is provided via the installation manual.
How are access domain elements checked?
When a process requests access to a file its appropriate fs access domain (rw in case of read and write request and ro in case of read request) is checked in the following way: if the fs access domain contains the target file request is granted, if not fs access domain is checked for the parent dir of the target file and if it is found the request is granted. If the parent dir is not found the parents’ parent is checked in a similar way. This goes on until the first mount point is reached. If still no match is found, request is denied.
There is another case when request is denied as well and that is when a match is found but it is marked with the EXCL flag in the fs access domain as an exclusion from the fs access domain.
Example: consider an fs access domain group having /etc directory as its element. User xyz is a rw member of the group and he wishes to remove /etc/foobar/blah file. When he issues the rm command, LinSec fs access domain algorithm tries to find /etc/foobar/blah in the rm process’ rw fs access domain. It fails. Then it looks for /etc/foobar. It fails again. Next, it manages to match /etc and grants access. Result: rm was successfull.
Now consider /etc/foobar is a mount point. The scenario is the same to the above. But now, when the algorithm fails to find /etc/foobar in the rw fs access domain it fails the request. This is due to the fact that the algorithm stops on the first mount point encountered.
Finally, consider that the user xyz was a ro and not rw member of the group. The scenario is the same to the first one. But, unlike the first time, the algorithm fails to find /etc in process’ rw fs access domain and continues executing. The next element it tries to match is /. It fails. As / is a mount point the whole request fails.
How does fs access domain model fit into existing rwx acl model?
LinSec fs access domain model operates at a higher level to the traditional rwx acl model. This means that when a fs request is issued by a process LinSec fs access domain algorithm is executed first and only if it grants access is the traditional rwx access control mechanism invoked. So, to be able to access a file, a process has to be granted access by both the mechanisms.
Filesystem access domain privilege revocation
All changes to fs access domain configuration take effect instantaneously. There is no need to reboot the system. Changes to file related access domain settings take place when the binary is executed after the change. User related access domain changes take place as soon as the tool confirms the change.
Do not be confused, if you change fs access domain settings for the shell they will not take effect until you log in again!
How to bypass fs access domain checks
To bypass all fs access domain checks boot your system with the boot parameter:
linsec=off
For the curious & ambitious
Assume you have a nicely configured access domain group which suits most of your needs. Suddenly you install a program that needs in its fs access domain exactly the elements you already have in the mentioned group but the only problem is that one of the elements should have NINH flag set. Should you create a separate fs access domain group which has exactly the same contents as the previous one except just for a flag of one single element? No! LinSec has a feature which enables you to override flag values of elements of groups that an executable belongs to! Hint: explore adadm -F -?