Please answer to this mail on [EMAIL PROTECTED]

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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to