Date: Thu, 25 Jun 1998 01:40:30 -0400 From: "Allen Smith" <easmith@beatrice.rutgers.edu> To: dg@root.com, tqbf@pobox.com Cc: njs3@doc.ic.ac.uk, dima@best.net, security@FreeBSD.ORG, abc@ralph.ml.org, tqbf@secnet.com, easmith@beatrice.rutgers.edu Subject: Re: bsd securelevel patch question Message-ID: <9806250140.ZM4804@beatrice.rutgers.edu> In-Reply-To: "Allen Smith" <easmith> "Re: bsd securelevel patch question" (Jun 24, 11:05pm) References: <199806241847.LAA01163@implode.root.com> <9806242305.ZM4253@beatrice.rutgers.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for replying to my own mailing, but I wrote it rather too hastily and have realized a few errors. On Jun 24, 11:05pm, Allen Smith wrote: > There is then the problem of telling which setuid files should have > their group list initialized. The best way to tell this would appear > to be the currently unused sticky bit (unused for executables, at > least). When a setuid file with the sticky bit was executed: > A. kern_exec would check for the new uid's listing in the data > set created by the above system call > B. if the uid was found, the groups would be initialized to > the groups of the new uid, except that the 0th gid would be > left unchanged unless the executable was also setgid; the > 1st gid would, as usual, contain the 'password gid' of the > new uid > C. a flag would be set in the process in question indicating > that this had been done D. optionally, the original group list would be saved, minus the 0th gid > Whenever another process was executed by a process with the flag set, > so long as that process was not setuid with the sticky bit set: Correction: whenever another process was executed that did _not_ have the sticky bit set in its file. > A. the groups list, other than the 0th gid (left the same as > before), would be reinitialized to that of the real uid > (possibly unless the result was the same group list, in > which case the saved uid would be used instead) Alternatively (and possibly preferably), use the original group list (except for the 0th gid). > B. the flag would be unset > Whenever the uid or euid of a process with the flag set was changed: > A. the groups list, other than the 0th gid (left the same as > before), would be reinitialized to that of the new uid > B. if the real, effective, and saved uids were all the same, > the flag would be unset Correction: Whenever the euid of a process with the flag set was changed, the groups list (other than the 0th gid - left the same as before) would be reinitialized to that of the new uid. Whenever the euid, real uid, or saved uid was changed, on a process with the flag set, if they were now all the same, the flag would be unset. Some further notes: Scripts under this would be done either via wrappers or via curing the problems with setuid/setgid scripts in the first place; sperl and relatives would not work right, unfortunately... but this would be true with a privileges setup also, so far as I can tell. If it's not clear, the above mechanism is designed to give a binary the ability to be non-root but still setuid, with the necessary privileges being available, and for the normal current (namely the saved uid and uid switching) mechanisms to be used for turning the extra abilities. Note on this that the nosuid switch should probably also turn off recognition of above-65535 (or whatever - should be configurable) gids over NFS, or of uids having such by default. This is admittedly a problem as compared to the non-group privileges setup, although I'm not sure how many filesystem operations should have the necessary privileges modified in any event. -Allen -- Allen Smith easmith@beatrice.rutgers.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9806250140.ZM4804>