zfs discuss - Jul 2006 - Progress update about implementing the new basic privileges to restrict file access

Please answer to this mail on security-discuss at opensolaris.org

Two weeks ago, the list discussed my OpenSolaris Google Summer of Code proposal
of introducing new basic privileges in order to be able to restrict file access.
My first proposal was to introduce five new privileges that if dropped forced
the process to act like an anonymous process, that means it can only access
world readable/executable/searchable/writable files and directories. These
privileges may be used for programs like ssh-agent or daemons that do not rely
on file access granted by their uid.

The list responded with naming changes, we discussed when files should be
allowed to be created and if there should be a possibility to restrict
file/directory access at all. We came up to the point that I should start
implementing a prototype for an easy file system (I chose tmpfs) to evaluate the
impact of the new privileges.
 
Meanwhile I successfully tested my kernel modifications that introduced seven
new basic privileges in OpenSolaris. I used the input of the list for naming and
semantics and also introduced a new policy when creating objects is allowed.

Please note that this neither the new privileges nor the code of the prototype
are official in any way. It worked fine for me, it is linted and follows the
correct style and I tested it with my test suite but if the code or the new
privileges will be accepted is beyond my competence.


The currently new implemented basic privileges are the following:


--------------
basic privilege PRIV_FILE_NANON_READ

	Without having set PRIV_FILE_NANON_READ, a process is only able
	to perform read operations on globally readable files or directories
	because it can only act like an ''anonymous process'' and
cannot benefit
	from its euid, egid or group memberships.
	Additional rights gained through PRIV_FILE_DAC_READ will not be
	restricted if PRIV_FILE_NANON_READ is not set.

basic privilege PRIV_FILE_NANON_WRITE

	Without having set PRIV_FILE_NANON_WRITE, a process is only able
	to perform write operations on globally writable files or directories
	because it can only act like an ''anonymous process'' and
cannot benefit
	from its euid, egid or group memberships.
	Additional rights gained through PRIV_FILE_DAC_WRITE will not be
	restricted if PRIV_FILE_NANON_WRITE is not set.

basic privilege PRIV_FILE_NANON_EXECUTE

	Without having set PRIV_FILE_NANON_EXECUTE, a process is only
	able to perform execute operations on globally executable files because
	it can only act like an ''anonymous process'' and cannot
benefit from its
	euid, egid or group memberships.
	Additional rights gained through PRIV_FILE_DAC_EXECUTE will not be
	restricted if PRIV_FILE_NANON_EXECUTE is not set.

basic privilege PRIV_FILE_NANON_SEARCH

	Without having set PRIV_FILE_NANON_SEARCH, a process is only
	able to perform search operations on globally searchable directories
	because it can only act like an ''anonymous process'' and
cannot benefit
	from its euid, egid or associated groups.
	Additional rights gained through PRIV_FILE_DAC_SEARCH will not be
	restricted if PRIV_FILE_NANON_EXECUTE is not set.

basic privilege PRIV_FILE_NANON_OWNER

	PRIV_FILE_NANON_OWNER allows a process to perform operations on
	a file, directory or link that require ownership.
	PRIV_FILE_OWNER may substitute PRIV_FILE_NANON_OWNER.
	Without having set at least one of both privileges, a process is
	considered to be ''anonymous'' and cannot benefit from its
euid.
	Affected operations are e. g. changing permission bits/acls, changing
	access and modification times, changing the gid of an owned file or
	directory when a process is member of this group, creating hardlinks to
	files owned by a UID equal to a process''s effective UID, renaming or
	moving in a directory with the sticky bit and creating of a new file,
	directory or symbolic link.
	To change permission bits/acls of an owned file PRIV_FILE_NANON_READ
	or PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or PRIV_FILE_DAC_WRITE and
	PRIV_FILE_ANON_EXECUTE or PRIF_FILE_DAC_EXECUTE have to be set as well.
	To change permission bits/acls of an owned directory
	PRIV_FILE_NANON_READ or PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or
	PRIV_FILE_DAC_WRITE and PRIV_FILE_ANON_SEARCH or PRIF_FILE_DAC_SEARCH
	have to be set as well.
	To change the gid of an owned file or directory when a process is
	member of this group, at least one of PRIV_FILE_NANON_OWNER,
	PRIV_FILE_OWNER, PRIV_FILE_CHOWN or PRIV_FILE_CHOWN_SELF has to be set.
	So privilege escalation due to permission changes are not possible.
	If a new file should be created PRIV_FILE_NANON_READ or
	PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or PRIV_FILE_DAC_WRITE and
	PRIV_FILE_ANON_EXECUTE or PRIF_FILE_DAC_EXECUTE have to be set as well.
	If a directory should be created PRIV_FILE_NANON_READ or
	PRIV_FILE_DAC_READ, PRIV_FILE_NANON_WRITE or PRIV_FILE_DAC_WRITE and
	PRIV_FILE_ANON_SEARCH or PRIF_FILE_DAC_SEARCH have to be set as well.
	So a process that was able to create a file or directory is always able
	to reopen or enter it later as long no privileges are removed
	from its effective set.
	Additional rights gained through PRIV_FILE_OWNER will not be restricted
	by PRIV_FILE_NANON_OWNER.

basic privilege PRIV_FILE_GEN_RES

	Without having set PRIV_FILE_GEN_RES, file or directory
	operations that require read/execute/search permissions will generally
	not possible unless the corresponding
	PRIV_FILE_DAC_{READ|EXECUTE|SEARCH} privileges are set.
	Set PRIV_FILE_NANON_{READ|EXECUTE|SEARCH} privileges will be
	ignored.

basic privilege PRIV_FILE_GEN_WRITE

	Without having set PRIV_FILE_GEN_WRITE, file or directory
	operations that require write permissions will not be possible at all
	unless the PRIV_FILE_DAC_WRITE privilege is set.
	A set PRIV_FILE_NANON_WRITE privilege will be ignored.


-------------------

With this approach, it is easy to deny read/write file access at all but you
also have the possibility to allow file access to globally
readable/writable/serachable/executable files only, that means switching your
process to "anonymous" mode.

All new privileges are already integrated and tested in my tmpfs prototyppe, all
file systems that call secpolicy_vnode_setattr are also influenced in their
behaviour (this applies to chown, utime, chgrp and chmod).

You may review the code under http://myhpi.de/~nicolai/webrev/ as a webrev.
Please tell me what you think about it.
If you are interested in a rudimentary test suite, let me know as well (the test
suite currently is a ksh script that calls about 30 basic commands privileges
removed / added to the effective set with priviilege debugging on. The result is
always as expected).

The next consequent steps for me would be to modify some programs like ssh-agent
to use the new privileges. Please tell me your ideas if you think another
program should drop them too.

Furthermore, I have developed a procedure to integrate the new privileges in
other file systems as well (chown, utime, chgrp and chmod work as expected for
every file system but I need to modify the access- and create- functions for
every single file system).
Because my system is entirely UFS-based, I may modify this fs at first. If you
think, ZFS is more important for my prototype, let me know.

If you like to help with my prototype and integrate the changes in your
favourite file system, please let me know that I can tell you the exact
procedure in order not to miss a bit.

Please feel free to comment on any issue you see with the prototype or the new
privileges.

Thanks a lot

Johannes Nicolai
Open Solaris Summer of Code Student