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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:31:40 PDT