Messages in this thread | | | Subject | Re: a simple replacement for setuid and confinement systems | From | Casey Schaufler <> | Date | Tue, 7 Feb 2017 09:18:53 -0800 |
| |
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. >
| |