Date:   Tue, 7 Feb 2017 09:18:53 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Peter Grandi <pg@...ern.for.sabi.co.UK>,
        Linux kernel <linux-kernel@...r.kernel.org>,
        LSM <linux-security-module@...r.kernel.org>
Subject: Re: a simple replacement for setuid and confinement systems

On 2/7/2017 5:09 AM, Peter Grandi wrote:
> This message is "for the public record" so if in the future
> someone tries to patent something like the below mechanism this
> message can be cited as prior art.
>
> The mechanism would be to add to each process, along with its
> "effective" id (user/group) what I would now call a preventive id
> with the following rules:

Please write this up as a Linux Security Module (LSM)
and submit patches to the LSM list (added to the thread).

>   * The access given to a program is that common to both the
>     effective id and the preventive id (the intersection of the
>     permissions for the effective and preventive ids), which can
>     be no access.
>   * Both effective and preventive id are inherited on fork.
>   * On exec the preventive id (user/group) of a process is set
>     to the id of the executed file.
>   * Files are created as in regular UNIX/Linux semantics with the
>     effective id of the creating process.
>   * A program in a process may set the preventive id to the same
>     value as the effective id (or to any value if the preventive
>     id is zero). This results in the current UNIX/Linux non-set-id
>     semantics.
>   * A program in a process may set the effective id to the same
>     value as the preventive id (or to any value if the effective
>     id is zero). This results in the the current UNIX/Linux set-id
>     semantics.
>   * If the effective id of a process and its preventive id are
>     different, the process is "confined" to the set of resources
>     accessible by both. Therefore a user that does not fully trust
>     an executable can give access to just the resources it
>     strictly needs to access, by setting permissions so that the
>     id of the file containing the executable can access only those
>     resources.
>
> Note: there are some other details to take care of, like
> apposite rules for access to a process via a debugger. The logic
> of the mechanism is that it is safe to let a process operate
> under the preventive id of its executable, because the program
> logic of the executable is under the control of the owner of the
> executable, and that should not be subverted.
>
> The overall logic is that in the UNIX/Linux semantics for a
> process to work across two protection domains it must play between
> the user and group ids; but it is simpler and more general to have
> the two protection domains identified directly by two separate ids
> for the running process.
>
> The mechanism above is not quite backwards compatible with the
> UNIX/Linux semantics because it makes changes in the effective or
> preventive ids depend on explicit process actions, but it can be
> revised to be backwards compatible with the following alternative
> rules:
>
>   * Only if exec if for an executable file with the "sticky" bit
>     set the preventive id of the process is set to the id of that
>     executable file. The sticky bit in effect becomes the
>     confinement bit.
>   * If exec is for an executable file with the set-id (user/group)
>     bit set, then the effective id of the process is set to the
>     preventive id after this has been set to the id of the
>     executable file.
>   * This is probably not strictly necessary because almost all
>     system-provided executables on a typical UNIX/Linux system are
>     in files owned by id 0, so preventive ids would be 0 thus
>     resulting in no confinement like in traditional UNIX/Linux
>     semantics.
>
> Note: the implementation of either variant of the mechanism is
> trivial, and in particular adding preventive id fields to a
> process does not require backward incompatible changes as process
> attributes are not persistent.
>

Powered by blists - more mailing lists