pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/11/90)
In article <109958@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: tchrist> I consider non-superuser chown(2)s harmful. They screw up tchrist> anyone who's trying to do post-facto disk accounting or tchrist> pre-emptive disk quotas. On 7 Dec 90 11:12:57 GMT, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) commented: brnstnd> There is, however, one case where non-superuser chown()s would brnstnd> greatly help security. Setuid programs should to be able to brnstnd> switch files between the real and effective uids. Because this brnstnd> feature isn't available, many secure programs have to run as brnstnd> root rather than their own uids. This is true, except that the whole setuid mechanism of UNIX is flawed or incomplete. As you have remarked, some systems idiotically apply the maximum process limit per uid to the _effective_ uid... More interestingly, I have reasoned years ago about the chown(2) problem, and I have found the solution to both Christiansen's and Bernstein's concerns. It is very simple, and shows that the UNIX ownership mechanism is incomplete. Files should be like processes and have BOTH an effective and a real user id. Accounting would be based on the real id, and protection on the effective id. Transfer of files between two ids would be easily and safely accomplisehd if we allow a process running under one of the ids to set the other to be the same. Suppose that id A wants to pass ownership of a file to B; it would first change the euid of the file to B, and then B would change the ruid of the file to B too. This is not dangerous at all; B gets to pay for the file only if it wants to acquire its ownership. A, if B fails to change the real id to itself, can revert the euid to itself again. In other words: Unix files are exactly like process, they exist in two different dimensions, accounting and protection, and each must have its own id. Note that having real and effective id for files too also solves the problem of protection and accounting for space for protected subsystems like Ingres or LPD, which currently have three equally unpalatable choices: if they hold the files entrusted to them under the user's id they must run either as root or must make them readable/writable to everybody to be able to access them; if they change ownership to themselves then the user can no longer access them and also does not pay for the space it occupies. Final observation: adding read/effective user ids to any UNIX kernel probably requires half a dozen lines spread across a couple of headers and in the stat(2) implementation, a few recompilations, and reformatting and reloading filesystems. Frankly not a lot of work. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
rickert@mp.cs.niu.edu (Neil Rickert) (12/11/90)
In article <PCG.90Dec10191750@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >Files should be like processes and have BOTH an effective and a real >user id. Accounting would be based on the real id, and protection on the >effective id. > And next thing we will want processes to have a real real id, an effective real id, a real effective id and an effective effective id. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
adeboer@gjetor.geac.COM (Anthony DeBoer) (12/12/90)
In article <PCG.90Dec10191750@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Note that having real and effective id for files too also solves the >problem of protection and accounting for space for protected subsystems >like Ingres or LPD, which currently have three equally unpalatable >choices: if they hold the files entrusted to them under the user's id >they must run either as root or must make them readable/writable to >everybody to be able to access them; if they change ownership to >themselves then the user can no longer access them and also does not pay >for the space it occupies. There's a fourth choice: give the subsystem a group ID of its own. The files in the queue would remain owned by their original owner, but the GID would be "lp" or whatever, and the permissions 660. The directory itself would be owned by lp, or even by root with GID=lp, with permissions either 775 or 770 depending on whether it is necessary to prevent users from tampering directly with files that are already enqueued. The appropriate utilities (ie. the spooler, the "cancel" command, and so forth) would run setgid. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, GEAC J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
cliffs@playroom.East.Sun.COM (Clifford C. Skolnick) (12/14/90)
In article <PCG.90Dec10191750@odin.cs.aber.ac.uk> you write: > >Final observation: adding read/effective user ids to any UNIX kernel >probably requires half a dozen lines spread across a couple of headers >and in the stat(2) implementation, a few recompilations, and >reformatting and reloading filesystems. Frankly not a lot of work. Not everyone has the source to everything. What about software companies that have gone out of business? You could keep the only binary interface alive in the kernel, but you have no idea what the stat() should put in the UID field since you don't know what the application is going to do with it. This is a good example of a simple kernel change that will break many applications, too complicated. As a note, I do think this is a good idea but I would rather see the addition of access control lists to UNIX. Would provide all this and more. If your gonna change and break things, might as well make it worth it! Cliff -- Cliff Skolnick | "You give me the reason, you give me control. cliffs@sun.com | I gave you my purity, my purity you stole. Am I (716) 385-5049 | just too stupid to realize stale incense old sweat I think. I am. | and lies lies lies." -- Nine Inch Nails
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/20/90)
On 11 Dec 90 20:47:35 GMT, adeboer@gjetor.geac.COM (Anthony DeBoer) said:
adeboer> In article <PCG.90Dec10191750@odin.cs.aber.ac.uk>
adeboer> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> Note that having real and effective id for files too also solves the
pcg> problem of protection and accounting for space for protected subsystems
pcg> like Ingres or LPD, which currently have three equally unpalatable
pcg> choices:
Note that I have written "id" not "uid" -- there would need to be real
effective user _and_ group ids.
adeboer> There's a fourth choice: give the subsystem a group ID of its
adeboer> own. The files in the queue would remain owned by their
adeboer> original owner, but the GID would be "lp" or whatever, and the
adeboer> permissions 660.
This is a fairly common scheme (e.g. month, some mails), and uses the
uid for real uid and the gid for effective _u_id. By doing so you lose
the gid, as it is used to simulate the effective uid. This can be a
problem -- for example on systems I managed accounting was done by gid,
with breakdown by uid.
On the other hand you do have a point: there is a fourth unpalatable
choice which I had forgotten.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk