Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!att!att!mcdchg!ddsw1!proxima!lucio
From: lucio@proxima.UUCP (Lucio de Re)
Newsgroups: comp.os.minix
Subject: Re: Minix 1.5.10 Kernel hiccup.
Keywords: read_permissions
Message-ID: <2057@proxima.UUCP>
Date: 18 Jan 91 10:38:16 GMT
References: <1983@proxima.UUCP> <8751@star.cs.vu.nl>
Organization: FLAGSHIP Wide Area Networks - Cape Town
Lines: 39

In article <8751@star.cs.vu.nl> beugel@cs.vu.nl (Beugel Berend Jan) writes:
>lucio@proxima.UUCP (Lucio de Re) writes:
>
>>The problem? Being somewhat security conscious, I removed group and
>>other read permissions from the binaries in /bin and /usr/bin ...
>
>I was always told to NEVER use the setuid trick in any program unless it's
>absolutely necessary. To my knowledge programs that don't use it are much less
>dangerous (security wise) than programs that do.

Who said anything about SETUID?

>What's the trouble (from a security standpoint) with making binaries readable
>to everyone? All the big Unix versions that I know of don't seem to mind.

That's no recommendation. The moment you allow dial-up access to your
computer (as I do), you open yourself to problems. If then you also want
to accommodate Bulletin Board capabilities, or even not-too-trustworthy
access to your computer, it becomes possible for somebody to download
each and every executable from your machine if it happens to have to be
readable as well. In general, what's the point of having a separate
execute-only permission, if read permission is also required.

Also, keep in mind that a concerted effort by a hacker to break your
system is going to be greatly facilitated by being able to check the
ASCII strings in executables, and, were it really worth it, by
disassembling code to determine whether there are code flaws.

Lucio.

PS: No, I don't have any special reason to be security conscious, except
	that as a consultant I have to be aware of my clients' needs.

--
lucio@proxima.UUCP    or    ...!uunet!ddsw1!proxima!lucio
>
>Berend Jan Beugel.
>
>(beugel@cs.vu.nl)