documentation:rsbac_handbook:security_models:ff
=>  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

File Flags (FF)

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

Flag Value Checked for Notes
no_protection 0 ALL
execute_only 2 FILE, FIFO, SYMLINK
search_only 4 DIR
read_only 1 FILE, FIFO, SYMLINK, DIR
write_only 8 FILE, FIFO, SYMLINK
secure_delete 16 FILE File is blanked on delete and truncate (ext2, ext3, msdos/vfat, minix only)
no_execute 32 FILE
no_delete_or_rename 64 FILE, FIFO, SYMLINK, DIR new in 1.1.1, not inherited
append_only 256 FILE, FIFO, SYMLINK new in 1.1.2, write accesses are limited to APPEND_OPEN and WRITE, read accesses are allowed
no_mount 512 DIR Disallows mounting to this dir
no_search 1024 FILE, DIR, SYMLINK, FIFO Hides filesystem object completly and denies futher access to it
add_inherited 128 FILE, FIFO, SYMLINK, DIR Add inherited values from parent dir, not inherited itself

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).

REQUEST PREVENTING FLAGS
APPEND_OPEN FF_read_only FF_execute_only
CHANGE_GROUP FF_read_only FF_execute_only FF_append_only
MODIFY_ACCESS_DATA FF_read_only FF_execute_only FF_append_only
MODIFY_PERMISSIONS_DATA FF_read_only FF_execute_only FF_append_only
CHANGE_OWNER FF_read_only FF_execute_only FF_append_only
CHDIR FF_search_only
CREATE FF_read_only FF_search_only
DELETE FF_read_only FF_execute_only FF_no_delete_or_rename FF_append_only
RENAME FF_read_only FF_execute_only FF_no_delete_or_rename FF_append_only
EXECUTE FF_write_only FF_no_execute FF_append_only
LINK_HARD FF_read_only FF_execute_only
MOUNT FF_read_only FF_execute_only FF_write_only FF_append_only FF_no_mount
UMOUNT FF_read_only FF_execute_only FF_write_only FF_append_only FF_no_mount
READ FF_execute_only FF_write_only FF_search_only
READ_OPEN FF_execute_only FF_write_only FF_search_only
READ_WRITE_OPEN FF_read_only FF_execute_only FF_write_only FF_append_only
TRUNCATE FF_read_only FF_execute_only FF_append_only
WRITE_OPEN FF_read_only FF_execute_only FF_append_only
WRITE FF_read_only FF_search_only FF_execute_only

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

//
documentation/rsbac_handbook/security_models/ff.txt · Last modified: 2006/05/17 13:27 by kang

documentation/rsbac_handbook/security_models/ff.txt · Last modified: 2006/05/17 13:27 by kang
This website is kindly hosted by m-privacy