Messages in this thread |  | | Date | Wed, 18 Dec 1996 15:23:15 -0600 (CST) | Subject | Re: Linux Security: An Appeal | From | riordan@math ... |
| |
Andrew E. Mileski writes: > Let me try again to make my point: you cannot change the unix > security system without fundamentally changing unix to the point > where it is no longer unix, but something else instead.
True but it's not clear that that is a bad thing. If I hack my kernel so that user httpd can bind port 80 or that a mail reception agent can bind port 25 (so that they do not have to run as root) is it still Unix? If I then put this type of deviation from the standard unix set- up in a configuration file...
Begging the pardon of the list, I think that users are mostly unconcerned with the low level security policy of the kernel. If the kernel can run applications without giving them permissions that they did not need in the first place, what would that matter?
> Attempting to bolt on a new security system without completely > re-engineering an OS from the ground up, is bound to have > complications (quota is an example of this).
There you are onto something. It turns out that the main difficulty is maintaining a database of what program/subsystem needs what permissions to run. Finer granularity of permissions means more to keep track of.
I think that LD Landis and the people in the Unix Review article were suggesting that this low level security policy be pulled a bit further away from the kernel as to make the whole thing finer grained, more configurable and thus more secure.
-- james riordan@math.umn.edu / http://www.math.umn.edu/~riordan
|  |