Message-ID: <22681.50976.676169.341220@tree.ty.sabi.co.uk>
Date:   Tue, 7 Feb 2017 13:09:52 +0000
From:   pg@...ern.for.sabi.co.UK (Peter Grandi)
To:     Linux kernel <linux-kernel@...r.kernel.org>
Subject: a simple replacement for setuid and confinement systems

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:

  * 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