brian@cs.utah.edu (Brian Sturgill) (02/20/90)
I am looking for ways to make our SGI machines have a reasonable level of security. This is currently not the case because:: 1) The out-of-the-box setup makes it trivial for any user to become super-user just by booting the machine to the single user init level. 2) There may be functions in the diagnostic/software installation menus provided in the monitor that may allow similar breaches of security. (However, I know of none at this time.) 3) A lack of caution in the design of suid programs causes at least one major hole that could be exploited without rebooting. (Sorry for being vague, but being the least bit explicit would give the bug away to the "bad guys" too... If you want details send me mail identifing yourself as a responsible individual, the message should come from root. The machine you send the root mail from should be a machine I can recognize as belonging to a reputable place. I will then send a message back to root that will explain the problem.) 4) A ridiculous limit on group user lists, limiting them to not more than 200 characters makes it impossible to use group protection schemes for groups of more than around 20 people. Problem (1) bothers us the most at the moment; we have thought of several possible ways to deal with the problem but would like to see if better ways exist. It would also be nice if a discussion about such problems in general would ensue, hopefully resulting in SGI taking security issues a bit more seriously. So far, SGI has not been very helpful with this sort of problem. For example when (4) was reported here is a sample of the kind of response I got: ---------------- > you are right. > in libsun, getpwent and getgrent (etc.) use a 200 char buffer > instead of libc's 8k. SGI reduced the size in order to close a > bug that complained about inordinately large data segments in > small programs--claimed it resulted in bad virtual memory usage... > perhaps 200 is too small. > could you give me an idea of what a better upper bound would be? --------------- > hi. > i just filed SCR #8931. > that's the bug number. > i requested that the buffer be raised to 1K. > > refer to that number--give the bug report about a month-- > and cb in. at that time it will have a response-- added to it. > the response will say if there is a fix and what release it will > be included on. > > i will close out the call C0030. --------------- (After griping about the "We'll tell you if-and-when a --------------- month from now") The final answer from SGI was: > hello. > you will need to wait for the next release of software to > get the fix you requested. > it was not included in the 3.2.2 fixes tape. the 3.2.2 fixes tape > is not out the door yet, but is frozen. > > as a workaround, make the long groups (reada1, execa1) have no members. > newgrp won't be necessary to access files owned by those groups, just > a matching effective group-id or owner or other perm. matches. > > the drawback is that anyone can then "newgrp reada1', not just the users > in the long list. you could put a passwd on group--but it's not well > supported. (see newgrp(1M). ---------------- The "workaround" suggested is absurd, it defeats the whole purpose of having the groups in the first place. On my own I worked-out a partial solution... Make two groups X and Y that have the same group id, where X is the name of the original group. Split the original members of X between X and Y. Have X appear first in /etc/group. This works for most purposes. (Though if you run YP, I am not sure that X ought necessarily appear first in the file, as YP uses a hashing scheme). Due to this kind of response I have not yet bothered to report (3), but instead fixed it by making my own version of the offending program. Solutions considered for (1) include: a) Making a fake /etc/init that intercepts single user boots and requires the entry of the super user password before execing the real /etc/init. b) Modifying the /etc/init binary /bin/zz instead of /bin/sh for single user boots, so that /bin/zz can first require the super-user password. c) Perhaps an entry in inittab could be used to get the required password. I have not tried any of these yet as it involves guess work, and would have to be redone every time a new distribution came out. My hope is that either there is a better way I have missed, or else that SGI will decide to put in an option similar to Sun's, so that if the console does not have "secure" in /etc/ttytab then the super-user password is required before the single-user shell is available. Brian Sturgill brian@cs.utah.edu