lkml.org 
[lkml]   [2017]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: a simple replacement for setuid and confinement systems
From
Date
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.
>

\
 
 \ /
  Last update: 2017-02-07 18:19    [W:0.081 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site