This model defines some access flags for files, fifos, symlinks and dirs. Currently, the following flags are supported:

These flags are checked on every access to the given target types. Only users in system_role 'security officer' can change the flags.

Please note that the attributes are independent from each other and restrictive: All attributes that are set are applied, e.g. execute_only and no_execute together (or read_only and write_only) lead to no access.

Flags that are only checked for some target types are ignored for the other ones. This can be used to set e.g. search_only and execute_only on a dir - you can SEARCH (not READ!) in the dir and EXECUTE files in it, but nothing else.

To set more flags on a target you just add (or) their numerical values, for example: add_inherited+read_only = 129. This numerical value is the one used by the administrative tools.

The add_inherited flag is special: If set, the parent dir's flags are added (or'd) to the target's own flags. Attention: the flags no_delete_or_rename and add_inherited cannot be inherited, they must always be set explicitely!

By default all targets have only add_inherited (128) set. The root of the filesystem by default has no FF restriction, which means that if all targets have only add_inherited set, FF does not protect any target.

The following table explains the effects of the flags of the FF module with respect to the action requested on a file or other target. Not all flags are meaningful for all targets. For each request are listed the flags which PREVENT the request to be satisfied, i.e. the flags which forbid the action (from the list are missing the actions related to managing RSBAC and similar).

Thus for example FF_read_only permits: CHDIR, EXECUTE, READ, READ_OPEN; FF_execute_only permits: CHDIR, EXECUTE, CREATE; FF_write_only permits: WRITE, WRITE_OPEN, LINK_HARD, DELETE, RENAME, CREATE, CHANGE_OWNER, APPEND_OPEN, CHANGE_GROUP.

Above list does not apply to FF_no_search flag - by setting it all access is denied and file is completly hidden (both from direct access and directory listing)

Obviously since FF_read_only and FF_write_only have an empty intersection, if one sets both of them on the same target, no action is allowed on it! Instead if one sets both FF_read_only and FF_execute_only on the same target, only CHDIR and EXECUTE are permitted.

Example1:

Set write_only on a logging dir.
All log files created in that dir inherit the write_only flag,
thus the log can never be read unless the flag is removed.

Example1b:

Set append_only on a logging dir.
All log files created in that dir inherit the append_only flag,
thus the log can be read, but writing can only append to the file, unless the flag is removed.
Add flag write_only, if the files should not be read either.

Example2:

Set no_execute on /home.
All executables below that dir inherit this flag,
thus no user can execute files from her home directory, unless the flag is removed.

Example3:

Set no_delete_or_rename on /home.
User home dirs below can be added, removed and individually protected,
but the parent dir /home cannot be moved or replaced to fake other home dirs for most users.

File Flags should be used, if you need global access settings which are valid for all users.

Table of Contents: RSBAC Handbook
Back: Security Models