Date: Wed, 27 Jan 1999 12:06:12 -0500
From: "Jonathan A. Zdziarski" <[email protected]>
To: [email protected]Subject: Unix Security Kernel Changes
I'm curious why these things haven't/could not be implemented on current
releases of unix. I've seen a few of them in some OS's, but it seems like
everyone's so worried about breaking a standard, that we're compromising
security (where instead security should become the standard). These are
just a few ideas I've had after reading a bunch of papers and everybody's
emails...
- Non Executable Stack: I know SunOS has this feature, and there is a
kernel mod for linux, but I don't believe there is one for BSDi or other
OS's.
- Text Area Stack Sanity Checking: This may be a feature of the non
executable stack, or may not...but it seems like we should be able to
modify the kernel to challenge the memory address of the pointers against
the text area memory addresses to determine if it's out of range, then seg
fault if it is. AFAIK, there's no reason to have to execute anything in
the data stack (unless your program structure is really whacked). A
simple check for this would prevent most buffer overflow attacks (except
for rare circumstances like the old FreeBSD procfs vulnerability)
- More exhaustive use of group permissions combined with Suid read-only
permissions: Running sendmail under a 'mail' group combined with a kernel
that would allow SUID programs only to open files as suid would be a
non-standard-threatening way of allowing several programs to run without
having superuser access...and if they were compromised, the best you could
get would be a nobody shell that could read universla files (which is
still better than root). But what would be nice would be...
And then there are some really whacked ideas I've got that may be
beneficial if anyone's got the knowhow to experiment with them. They
would require breaking the standard, but if it can be proven to improve
security, perhaps it could become the new standard...
- Multiple group file permissions: This would obviously break the
UFS standard, but would certainly introduce a whole new possibility for
security. I've already seen several circumstances where I've had to run
programs setuid to get the job done that wouldn't need to run setuid if
files could have multiple group permissions.
- authid bit: Files with the authid could make authentication checks
without actually being root. The kernel would execute the auth commands
as root, but not allow the program to run as root.
- bind group permissions: if a program ran as setgid under a particular
group, it would be able to bind to ports < 1024 without being root
I'd love to hear some input.
Jonathan A. Zdziarski
Sr. Systems Administrator
Netrail, inc.
888.NET.RAIL x240
