[lkml]   [1996]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux Security: An Appeal

Alan Cox wrote:
>> 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...
>Anyone wanting to contribute an ipfw modification to allow you to set
>permissions on firewall entries is asked to contribute. Its an idea
>I've bounced around for ages but not found nice semantics for.

Here's an idea:

How about a proc directory: /proc/security

/proc/security would contain directories and files with
permissions on them. Virtually every system function already
has a group or user associated with it (ie mail, bin, etc.)

To set fine grained permissions on the http port (80 of course):

# cd /proc/security/tcp/
# touch 80 (file 80 is created with very strict default perms)
# chown root.http 80 (assuming http daemon runs with group http)
# chmod 770 80

And so on. File "80" could contain names of users or groups who
need to access it (here I am using group ownership to control
access) or could be directory "80" with files in it describing

Note that here I assume nonexistant files/directories will have
reasonably strict defaults.

1) We can add and subtract directories at will (I mean the
kernel developers, not the system administrator)

2) Everyone understands the group/user model, and existing
systems already have users and groups set up which would
probably map directly onto most of the permissions we want to
set on hardware, etc. Simply chown or chgrp the correct
files in /proc.

3) System daemons already have "personalities" ie user bin, man,
lp. These could be given whatever permissions in /proc are

4) System administration can be done from scripts, since the
tools are all existant:

cd /proc/security/tcp/80 || echo "Sorry, insufficient access."

(The execute permission could be a simple way to test whether
you are in a priveledged group.)

5) This avoids a redesign of the whole security layout, since
Unix has a long standing, well tested model, we are just
extending it from files to hardware/networking.

>I'd also strongly suggest at looking at the POSIX.6 work which is designed
>to cleanly handle issues like fine grained security. Remember however that
>fine grained security can also simply mean lots of smaller leaks
Develop free apps?
Pascal, n.: A programming language named after a man who would
turn over in his grave if he knew about it.

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