Bugtraq mailing list archives
Unix Security Kernel Changes
From: jonz () NETRAIL NET (Jonathan A. Zdziarski)
Date: Wed, 27 Jan 1999 12:06:12 -0500
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
Current thread:
- [HERT] ANNOUNCE: linux auditd daemon 1.10 Anthony C . Zboralski (Jan 26)
- Re: [HERT] ANNOUNCE: linux auditd daemon 1.10 Anthony C . Zboralski (Jan 27)
- Unix Security Kernel Changes Jonathan A. Zdziarski (Jan 27)
- Responses to: Unix Security Kernel Changes Jonathan A. Zdziarski (Jan 28)
- Re: Responses to: Unix Security Kernel Changes Paul Braman (Jan 29)
- WebTrends Security Analyzer v2.0 now available<WTID-100244707> wiseleo () BEST COM (Jan 29)
- Re: Responses to: Unix Security Kernel Changes Michael H. Warfield (Jan 29)
- Security Advisory for Internet Information Server 4 with Site mnemonix (Jan 30)
- Responses to: Unix Security Kernel Changes Jonathan A. Zdziarski (Jan 28)
- How the MS Critical Update Notification works... HD Moore (Jan 27)
- Re: How the MS Critical Update Notification works... Brian Hayward (Jan 28)
- EDA/SQL Victor A. Rodriguez (Jan 28)