lucio@proxima.UUCP (Lucio de Re) (01/14/91)
I hope this has not been addressed before I obtained a comp.os.minix
feed, if it has, please excuse me, I begged for months for the feed
and only recently has an alternative source of news arisen.
The problem? Being somewhat security conscious, I removed group and
other read permissions from the binaries in /bin and /usr/bin with the
result that only root can now execute programs. Shame! I took a look
at the EXEC code in the kernel and reached the following conclusions:
(a) EXEC attempts to establish whether the code is executable by opening
the file (O_RONLY) with the caller's UID and GID. Take away
read-permissions, and the call fails; hence problem.
(b) One solution seems to be to change the effective ID at that
point, but my feeble attempt at doing so failed, probably just
as well, as it looked somewhat insane. One must keep in mind
that EXEC needs to _read_ the input file to load it into memory
for execution.
(c) I also noticed that permissions are checked in two distinct
places, in FS and MM, very similar code being employed. Now, the
OPEN being executed by MM (in mm/utility.c) uses the FS
permission check (which we would probably prefer to bypass,
actually), the shortcut being that the file is conveniently left
open for EXEC to load it into memory. I wonder whether ideally
one should not create a new OPEN mode (O_XONLY), which (a) would
not be available at user level (shudder!) and (b) would include
read permission; the offshoot would be that the execute
permission would be checked by FS (and only once), the file
would remain open and the user would be none the wiser.
(d) It would also be expedient, while breaking the EXEC code, to add
the BSD #! capability (I do miss it somewhat), although I'd
rather see somebody more au fait with the kernel battling with
the re-entrancy (or lack thereof, who am I to know) of FS and MM.o
For the sake of discussion, I presume that, on encountering the
#! magic number, EXEC would scan the line and attempt to EXEC
the relevant process (that's the need for recursion) with the
remainder of the file as stdin. I appreciate that the shell is
quite capable of doing so, but considering that each program
execution has its very own memory image, independent of whether
it is already loaded or not (grump!), #!/bin/sh would result in
twice as much memory being used as is actually required.
Furthermore, one cannot have read-inhibited shell scripts
without such a facility (unless the Korn shell is used with
setuid root).
Enough complaints, I'll gladly exchange ideas with anyone who would
like to look into this problem, it's ridiculously dear to me. At the
same time, I apologize if the problem has already been addressed
(and also if I sounded off somewhat conceitedly).
Regards to all, nice having you around.
Lucio de Re, just another Minix fan.
---
lucio@proxima.UUCP or ...uunet!lll-winken!ddsw1!proxima!luciotim@proton.amd.com (Tim Olson) (01/16/91)
In article <1983@proxima.UUCP> lucio@proxima.UUCP (Lucio de Re) writes: | I hope this has not been addressed before I obtained a comp.os.minix | feed, if it has, please excuse me, I begged for months for the feed | and only recently has an alternative source of news arisen. | | The problem? Being somewhat security conscious, I removed group and | other read permissions from the binaries in /bin and /usr/bin with the | result that only root can now execute programs. Shame! I took a look | at the EXEC code in the kernel and reached the following conclusions: | | (a) EXEC attempts to establish whether the code is executable by opening | the file (O_RONLY) with the caller's UID and GID. Take away | read-permissions, and the call fails; hence problem. This has been noted before, but I don't remember what the previously-posted fixes were. However, I have a suggestion that looks feasible... | (b) One solution seems to be to change the effective ID at that | point, but my feeble attempt at doing so failed, probably just | as well, as it looked somewhat insane. One must keep in mind | that EXEC needs to _read_ the input file to load it into memory | for execution. | | (c) I also noticed that permissions are checked in two distinct | places, in FS and MM, very similar code being employed. Now, the | OPEN being executed by MM (in mm/utility.c) uses the FS | permission check (which we would probably prefer to bypass, | actually), the shortcut being that the file is conveniently left | open for EXEC to load it into memory. I wonder whether ideally | one should not create a new OPEN mode (O_XONLY), which (a) would | not be available at user level (shudder!) and (b) would include | read permission; the offshoot would be that the execute | permission would be checked by FS (and only once), the file | would remain open and the user would be none the wiser. I think the problem is that the tell_fs(CHDIR...) call in MM is trying to do two different things: 1) temporarily change MM's workdir to the original caller's workdir 2) change MM's effuid to the original caller's effuid The second action is really only required to creat() a core file with the correct ownership, since permissions are already checked in MM. [By the way, shouldn't the effgid also be changed? I believe that core files should have both effuid *and* effgid ownerships] The fix I propose is to split these actions by slightly modifying the do_chdir code in FS pertaining to a call by MM: cd_flag == 0: change MM's workdir to the original caller's workdir, set effuid to SUPER_USER cd_flag == 1: change MM's workdir back to MM's rootdir, set effuid to SUPER_USER cd_flag == 2: change MM's effuid and effgid to the original caller's effuid and effgid. With these changes in FS, the only change to MM needs to be in "signal.c", where the core file is creat()'ed -- just before the creat() call, we can add: tell_fs(CHDIR, slot, 2, 0); to set the user and group ownerships correctly. I haven't given this potential fix much rigorous thought; it just seemed to be correct to me. Anyone find any nasty holes in this? -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
tim@proton.amd.com (Tim Olson) (01/16/91)
In article <1991Jan15.162345.23304@mozart.amd.com> tim@amd.com (Tim Olson) writes:
I forgot to mention in my previous post that I am using a modified 1.2
kernel, not 1.5.10, so my proposed fix may not be applicable....
--
-- Tim Olson
Advanced Micro Devices
(tim@amd.com)lucio@proxima.UUCP (Lucio de Re) (01/18/91)
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)