Re: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds

Andrej Presern (andrejp@luz.fe.uni-lj.si)
Fri, 7 Aug 1998 23:39:50 +0200


On Thu, 06 Aug 1998, Chip Salzenberg wrote:
>According to Andrej Presern:
>> However, UNIX is broken with respect to security _by design_
>
>You'd better provide some specifics, or be relegated to "troll" status.

I have described a weakness in UNIX design in the mail that you quoted a part
of. This weakness, namely, is the inability to adequatelly support building of
small objects that obey the principle of least authority. This principle is
one of Schroeder's and Saltzer's eight design principles that apply to
protection mechanisms in an operating system, and that designers should keep
in mind when designing secure operating systems. The result of not obeying
those principles are various security flaws, one of which was discussed in the
thread that I originally replied to.

But perhaps you should also think about how (or the mere fact that) authority
is tied to identity, about granularity of access control, about the number,
versatility and complexity of security mechanisms present, about the inability
to confine, etc. Those are all design failures that relate directly to security.

The point that I tried to get accros was that as UNIX developed, many ad
hoc solutions were implemented that solved individual security related
problems. It is obvious that current security mechanism implementations have
various flaws (if this was not so, we would probably not be having this
conversation) and this leads to a logical conclusion that existing security
mechanisms did not fully solve security related problems that arose in the past
(or they produced other security related problems), so they are not very
different in this respect to the no-stack-exec patch. Refusing the inclusion of
the no-stack-exec patch into the kernel on the grounds that it is a partial and
ad hoc solution therefore doesn't seem to hold water. If such security flaws
are to be solved cleanly and fully, some design decisions should be revised and
parts of the system should be redesigned. And this is obviously not a short
term thing, whereas users need solutions now.

Andrej

--
Andrej Presern, andrejp@luz.fe.uni-lj.si

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html