Responses to: Unix Security Kernel Changes

[jonz () NETRAIL NET (Jonathan A. Zdziarski)]

  I was asked to summarize several of the responses I've received and send
it to the list.  I'll try to do the best I can, however I've received such
a widespread variation in responses it may be difficult.  Ideas that some
people thought were wonderful, others thought were stupid and vice versa.
Here is my attempt to consolidate the past 30 emails I've received...

BTW: New question at the end of this email

> - 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.

RESPONSES:

1. The non executable stack presents several problems to trampolining,
which, as far as I can tell, has something to do with threading (I'm not a
C hack).  It also interferes with SMP.  I'm unclear if the non executable
stack features of solaris break these kinds of programs altogether or not.

2. Someone at BSDi thought it was a good idea, and may be implemented some
day.

3. using NES does not get rid of the possibility of buffer overflow
exploits (although it does help make them more difficult).  I personally
feel that nothing but good programming will prevent problems such as
these.

> - 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)

RESPONSES:

1. "What the hell are you talking about?"

2. This has been attempted before, and caused severe CPU delay

3.  It still wouldn't solve the vulnerability problems

> - 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...

RESPONSES;

While it is agreed that the use of groups can greatly reduce the amount of
setuid processes, there was some debate about a read only setuid bit.
Some people liked the idea.  Others did not...others liked it, but did not
see how it could be implemented.  Basically all I was saying is that
programs like this act like regular programs, only fopen() routines (and
any other file opening routines that are part of the std c lib) be somehow
executed as superuser.

> - 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.

RESPONSES:

1. Think ACL
2. MetaGroups

> - 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.

RESPONSE: Good concept, wrong implementation.  Auth daemon is the way to
go (I'm not against this, but last time I mentioned an auth daemon nobody
wrote me back).

> - 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

RESPONSES:

1. Very good idea
2. Linux has a patch for it but it sucks
3. It shouldn't be too hard to patch
4. You could set up a whole acl for that if you wanted to



OK NOW:  Let me introduce a new question to you.  How come we cannot
write our std c libraries to do something similar to this before
performing strcat's, etc...

a[sizeof(b)] = NULL (or 0);

to nullify out position x of the variable being copied from where b is the
variable being copied to ... so if b is a 128 byte array, a[128] =
0...if there's a null before that fine...it will stop there...if not, it
will forcibly stop at 128 when it hits the null.


Thank you,

Jonathan A. Zdziarski
Sr. Systems Administrator
Netrail, inc.
888.NET.RAIL x240