Bugtraq mailing list archives
Re: UnixWare
From: mouse () collatz mcrcim mcgill edu (der Mouse)
Date: Wed, 27 Apr 1994 15:14:31 -0400
Personally, I can think of all sorts of security flaws at the kernel level that have NOTHING to do with setuid programs.Name a couple for us then.
I'm not the person who posted the text you're challenging, but.... Item: I don't know of any system that behaves completely correctly with respect to disconnecting programs from pseudo-ttys when they (the ptys) get closed. Many of the older systems still in use at smaller sites are positively dismal here. Item: Many older systems, and at least one quite recent Ultrix version, are vulnerable to a denial-of-service attack that is often duplicated without malicious intent by firewalls: on receiving a single host unreachable, they summarily shut down all connections to that host; some may also do this for net unreachables, but I don't know. Item: NFS has numerous security flaws (as anyone who's been following this list recently knows!), some of which cannot be fixed because they're design bugs, and most systems supporting NFS have it in the kernel. Find me a few days of spare time to go reacquaint myself with kernels and I could probably name you a couple more.
Virtually every alert is related to a program thats setuid root, or that is needlessly running with root privileges (like sendmail).(And then, I can also think of a few associated with programs that CAN'T be run non-setuid).Many programs cannot be run non-setuid. Few functions, however, cannot be accomplished entirely with non-suid programs.
Not to claim that there aren't too many suid-root programs around; on that point I agree with you - but this claim of yours strikes me as unreasonably strong, unless you're proposing to rework large fractions of the system. For example, utmp writers could be changed from suid root to sgid utmp...until you find one that needs to perform some other function that you've moved from suid-root to a group of its own (kmem, for example, or tty). All these could be fixed by redesigning the mechanisms in question - the way utmp is maintained, for example - and reimplementing all the relevant programs with the new paradigm. Where do you draw the line between fixing a program and redesigning the system? der Mouse mouse () collatz mcrcim mcgill edu
Current thread:
- Re: UnixWare, (continued)
- Re: UnixWare Gene Spafford (Apr 28)
- Re: UnixWare Carl Corey (Apr 27)
- Re: UnixWare der Mouse (Apr 27)
- Re: UnixWare Casper Dik (Apr 27)
- Re: UnixWare Perry E. Metzger (Apr 27)
- Re: UnixWare Bonfield James (Apr 28)
- Re: UnixWare Perry E. Metzger (Apr 27)
- Re: UnixWare Michael Neuman (Apr 27)
- Re: UnixWare Ron McDowell (Apr 27)
- Re: UnixWare John Macdonald (Apr 27)
- Re: UnixWare Perry E. Metzger (Apr 27)
- Re: UnixWare der Mouse (Apr 27)
- Re: UnixWare Scott Schwartz (Apr 27)
- Re: UnixWare Bennett Todd (Apr 27)
- Re: UnixWare Perry E. Metzger (Apr 28)
- Re: UnixWare (I think it's time to pick a new subject) Doug Hughes (Apr 28)
- Re: UnixWare Marc W. Mengel (Apr 29)
- Re: UnixWare Daniel R Ehrlich (Apr 28)
- Re: UnixWare Perry E. Metzger (Apr 28)
- Re: UnixWare Bennett Todd (Apr 27)
- Re: UnixWare Bennett Todd (Apr 28)