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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ