Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!olivea!orc!inews!iwarp.intel.com!gargoyle!ddsw1!proxima!lucio
From: lucio@proxima.UUCP (Lucio de Re)
Newsgroups: comp.os.minix
Subject: Minix 1.5.10 Kernel hiccup.
Summary: Have you tried removing read permissions from /bin/sh?
Keywords: read_permissions
Message-ID: <1983@proxima.UUCP>
Date: 14 Jan 91 14:29:29 GMT
Organization: FLAGSHIP Wide Area Networks - Cape Town
Lines: 57

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