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

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- documentation:different_models:ff [2005/10/27 12:20] – michal
+++ documentation:different_models:ff [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-===== 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.
-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:
-<code>
-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.
-</code>
-Example1b:
-<code>
-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.
-</code>
-Example2:
-<code>
-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.
-</code>
-Example3:
-<code>
-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.
-</code>
-File Flags should be used, if you need global access settings which are valid for all users.

//