Date: Fri, 24 May 2002 13:51:16 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Andy Sporner <sporner@nentec.de> Cc: freebsd-hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Can I get some comment on my RFC??? Message-ID: <3CEEA7C4.B08415DD@mindspring.com> References: <3CEDFEEB.30305@nentec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Andy Sporner wrote: > Hi Hackers, > > I would really like to have some input otherwise I might consider how > usefull my > participation on this list really is... Well, far be it for me not to comment, particularly if the lack of comments could hinder your future participation... To me, this looks like a partial implementation of resource containers, with the ability to put each process into an arbitrary resource group. If your need is to track all processes owned by "init", which is what you say, then really, you are trying to solve a much smaller problem than the patches you give solve. It seems to me that you could do the same thing by being able to obtain an arbitrary parent process ID. However, I think your patches are really very useful. Personally, I would use them in a dial on demand gateway device, like an InterJet, Encanto, Cobalt Qube, Celestix, etc.. I would use the application ID to decide, on a per application basis, whether to permit or deny "link up". Normally, a link is brought up on demand, and that demand is based on traffic. Knowing who is the source of the demand would permit you to handle administrative restrictions on who is permitted to create demand, and when. So, for example, you could have "office hours", during which web surfing is prohibited (to offer a lame example that we were forced to implement on the InterJet). Thus if the "demand" was name resolution coming from the web proxy server, you prohibit the socket open; whereas if it is name resolution for outgoing email, you don't. Obviously, you could do this by GID, instead, if your different classes of "demanding users" ran under different default GIDs; and since an applicaiton could run under a GID via a single system call, and since it's required to make a system call to run under a different "application ID"... I'm not really positive that you've done anything that's really orthogonal to the default GID, in terms of providing additional information -- with the exception of the inheritance. I would suggest that you restrict access to the cse_set_id(2) call. I would also suggest that you change it's name, and make it a mux system call: it's likely that people are going to find all sorts of things they want to do with the value of this; an obvious one will be "getcseid", and another obvious one will be "getpcseid" (this latter is lacking for groups; thus your ID bears the same relationship to GID as UID bears to GID; i.e. it's an orthogonal credential value). My suggestion would be "AID" -- for "application ID". I would also be very tempted to make this an attribute of the application executable -- an optional value which is set by the loader during load. You probably need to consider the security ramifications of someone setting a value other than one they are permitted to use (e.g. "lying"). This probably means that this is an inode attribute, rather than an ELF attribute. An alternate approach would be to hash a string value based on the application name. The problem with this is that you would have to decide on inheritance or replacement, over an "exec". I would suggest the use of the inode for the process, and setting an inheritance flag. The problem with an inode is that it is only per-FS unique, and PHK is turning it from a 32 bit to a 64 bit value, so that's probably not a useful unique identifier. But however you arrive at it, you could still turn on/off inheritance over a fork. The way to do this would be to use "rfork" instead of "fork", and set all the flags to make it identical to fork, plus set the "inherit AID" flag. We did a similar thing to this in UNIXWare. In UNIXWare, I designed an "rfork-like" behaviour. The way this worked was by allowing inheritance of the per process open file table by a child process. The general mechanism for this was for a process to open it's own process ID in procfs, and then ioctl() down a flag that said "when forking, add a reference to the parent open file table, instead of copying one for yourself". I had some help from a rather intelligent young woman from New Jersey, who did work on implementing the design. I believe it's still in UNIXWare today. In any case, the patches you gave are an OK experimental version of the code, but lack the necessary security considerations and applications considerations which render them different from just using the active GID to control the same thing. IMO, you would need to expand the scope of their applicability in order for them to have value, and needing a "setuid" program to control setting of them, or the value of defaults, is really not a wonderful thing (though a workarouns would be to set an inheritable value with a wrapper program that then exec'ed the program of interest). Right now, I think it solves your own problem, but it's really too domain specific and insecure to be generally useful. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CEEA7C4.B08415DD>