lkml.org 
[lkml]   [1996]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux Security: An Appeal
From



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

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.048 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site