[<prev] [next>] [day] [month] [year] [list]
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: OSS Security <oss-security@...ts.openwall.com>
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
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
