tchrist@convex.COM (Tom Christiansen) (01/29/91)
From the keyboard of maart@cs.vu.nl (Maarten Litmaath): :How does Perl implement `-x', Tom? It does its own stat, and then does the bit compares itself to determine accessibility; it does not use access(2). Note that both -x and -X exist for checking effective and real IDs respectively; likewise -r/-R, -w/-W, and -o/-O. Does this solve your problem? Could you show me some, um, test cases where /bin/test fails so I can see what perl does under the same circumstances? --tom ps: Isn't this a much nicer forum now? :-) -- "Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now he can finally have the whole O/S built-in to his editor like he always wanted!" --me (Tom Christiansen <tchrist@convex.com>)
maart@cs.vu.nl (Maarten Litmaath) (01/31/91)
In article <1991Jan29.153242.12335@convex.com>, tchrist@convex.COM (Tom Christiansen) writes: )From the keyboard of maart@cs.vu.nl (Maarten Litmaath): ):How does Perl implement `-x', Tom? ) )It does its own stat, and then does the bit compares itself to )determine accessibility; it does not use access(2). Good! )Note that both -x and -X exist for checking effective and real IDs )respectively; likewise -r/-R, -w/-W, and -o/-O. Does this solve )your problem? I guess so. )Could you show me some, um, test cases where /bin/test )fails so I can see what perl does under the same circumstances? As root: $ test -x /etc/passwd && echo 'Huh? /etc/passwd is executable?' If your effective uid is that of user `foo', whereas your real uid is that of user `bar': $ ls -l mailbox -rw------- 1 foo 1079 Jan 30 19:26 mailbox $ test -r mailbox || echo 'Huh? Is mailbox unreadable for me?' Access(2), a sick system call. (I _know_ it uses the real uid on purpose.) -- Temporary files like /tmp/sh$$ are an abomination.
jfh@rpp386.cactus.org (John F Haugh II) (01/31/91)
In article <8896@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >If your effective uid is that of user `foo', whereas your real uid is >that of user `bar': > > $ ls -l mailbox > -rw------- 1 foo 1079 Jan 30 19:26 mailbox > $ test -r mailbox || echo 'Huh? Is mailbox unreadable for me?' > >Access(2), a sick system call. (I _know_ it uses the real uid on >purpose.) The question test(1) is asking is wrong. test is supposed to return whether or not it =is= readable, not whether it =should= be readable. test(1) is the sick on. Any version of test(1) which relies on access(2) is broken. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "13 of 17 valedictorians in Boston High Schools last spring were immigrants or children of immigrants" -- US News and World Report, May 15, 1990
maart@cs.vu.nl (Maarten Litmaath) (02/02/91)
In article <19017@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: )[...] )>Access(2), a sick system call. (I _know_ it uses the real uid on )>purpose.) ) )The question test(1) is asking is wrong. test is supposed to return )whether or not it =is= readable, not whether it =should= be readable. ) )test(1) is the sick on. Any version of test(1) which relies on )access(2) is broken. Agreed. I guess many if not most implementations of test(1) are broken in this way. BTW, access(2) still hasn't recovered from its illness. The last thing it wishes to achieve before it dies, is to enter the Guinness Book of World Records as the system call that received the most complaints. -- Temporary files like /tmp/sh$$ are an abomination.
jim@segue.segue.com (Jim Balter) (02/02/91)
In article <19017@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >test(1) is the sick on. Any version of test(1) which relies on >access(2) is broken. 1) The fact that access does not provide an option to test the effective uid is brain damage. 2) It only matters if the program calling access has S_ISUID or S_ISGID set. Why would test be installed with set-uid privileges?
maart@cs.vu.nl (Maarten Litmaath) (02/02/91)
In article <6124@segue.segue.com>, jim@segue.segue.com (Jim Balter) writes: )In article <19017@rpp386.cactus.org> ) jfh@rpp386.cactus.org (John F Haugh II) writes: )>test(1) is the sick on. Any version of test(1) which relies on )>access(2) is broken. ) )1) The fact that access does not provide an option to test the effective uid ) is brain damage. And the following piece of kernel code: /* * If you're the super-user, * you always get access. */ if (u.u_uid == 0) return (0); )2) It only matters if the program calling access has S_ISUID or S_ISGID set. Not true. ) Why would test be installed with set-uid privileges? What if the program (e.g. the shell) that _calls_ `test', is setuid? (I.e. its effective uid differs from its real uid.) -- "Salman Rushdie received a copy just as his latest novel was being published. He ignored it and received myriads of death threats. He quickly decided to send out twenty copies (some to the Ayatollah) and is still alive." (John Banagan <jvbanagan@ucdavis.edu> in sci.skeptic)
ripley@netmbx.UUCP (Hans-Ch. Eckert) (02/02/91)
In article <19017@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: ]In article <8896@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: ]>If your effective uid is that of user `foo', whereas your real uid is ]>that of user `bar': ]> ]> $ ls -l mailbox ]> -rw------- 1 foo 1079 Jan 30 19:26 mailbox ]> $ test -r mailbox || echo 'Huh? Is mailbox unreadable for me?' ]> ]>Access(2), a sick system call. (I _know_ it uses the real uid on ]>purpose.) You mean like this? ripley% su alg053 (ripley)alg053% ls -l /usr/spool/mail/alg053 -rw------- 1 alg053 5940 Feb 2 02:32 /usr/spool/mail/alg053 (ripley)alg053% test -r alg053 || echo 'What happens?' (ripley)alg053% Seems like SunOS 4.1 does it right... ]The question test(1) is asking is wrong. test is supposed to return ]whether or not it =is= readable, not whether it =should= be readable. At least on a sun it returns that the file is readable, which is true. Greetings, RIPLEY -- Hans-Ch.Eckert, Regensburger Str. 2, D-1000 Berlin 30 [Tel: +49 030/246292] eMail: ripley@netmbx.uucp (ripley%netmbx.uucp@db0tui6.bitnet [saves $$$]) Quote: "I'd rather type "cc fubar.c" than point-click-point-click-point- click-point-click-knock-over-my-coffee-cup." [Steve Yelvington, 2-11-89]
jim@segue.segue.com (Jim Balter) (02/04/91)
In article <8920@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >)2) It only matters if the program calling access has S_ISUID or S_ISGID set. > >Not true. Is this proof by assertion? Tell me how it's not true. >) Why would test be installed with set-uid privileges? > >What if the program (e.g. the shell) that _calls_ `test', is setuid? >(I.e. its effective uid differs from its real uid.) The shell shouldn't be set-uid if you have any concern for security, but even if it were, exec pays no attention to the set-uid bit of the caller. You seem to be confusing the effects of su, which changes your real and effective uid, with the setuid bit on an executable. Doing an su *does not* make your shell setuid. Test will only have different real and effective uids if the S_ISUID bit is set on the executable file. This not to say that there aren't plenty of programs that do access calls that break when someone decides to make them set-uid. Because there is no effective uid access call, these programs are forced to use stat, which costs more on many systems (acc/mod/chg times aren't kept in core because of old pdp11 space constraints), and do their own access determination based on protection bits, even though such determination is system-dependent these days, given group sets and access lists.
thorinn@diku.dk (Lars Henrik Mathiesen) (02/04/91)
jim@segue.segue.com (Jim Balter) writes: >In article <8920@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >>)2) It only matters if the program calling access has S_ISUID or S_ISGID set. >> >>Not true. >Is this proof by assertion? Tell me how it's not true. It simply isn't. (Reason below.) >>What if the program (e.g. the shell) that _calls_ `test', is setuid? >>(I.e. its effective uid differs from its real uid.) >The shell shouldn't be set-uid if you have any concern for security, but even >if it were, exec pays no attention to the set-uid bit of the caller. But exec (and fork) don't care about the real uid either, so it is just inherited. If a shell has different real and effective uids, any process run by that shell will too (unless it happens to be setuid to the real uid). And the shell in its turn could have been started by a setuid program that has a reason for being so. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/06/91)
The words "access()" and "security" should not be uttered in the same breath. Any system call that uses filenames to check permissions is insecure unless the operation you're checking permissions for is built into the same system call. Don't use stat() and then open(), for instance. You have no guarantee that the file you're opening is the same file that you stat'ed. Use open(), and then fstat() the descriptor, which is not subject to spoofing like filenames are. Don't close the file and then reopen it, either. Larry Wall lwall@jpl-devvax.jpl.nasa.gov
del@algol.mlb.semi.harris.com (Don Lewis) (02/06/91)
In article <1991Feb4.135842.28500@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes: >jim@segue.segue.com (Jim Balter) writes: >>In article <8920@star.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: >>>What if the program (e.g. the shell) that _calls_ `test', is setuid? >>>(I.e. its effective uid differs from its real uid.) > >>The shell shouldn't be set-uid if you have any concern for security, but even >>if it were, exec pays no attention to the set-uid bit of the caller. > >But exec (and fork) don't care about the real uid either, so it is >just inherited. If a shell has different real and effective uids, any >process run by that shell will too (unless it happens to be setuid to >the real uid). And the shell in its turn could have been started by a >setuid program that has a reason for being so. It sounds to me like the effective uid should be set back to the real uid before doing the exec()? Actually, I was under the impression that exec() did this automatically, but I just tried an experiment and found that I was mistaken. -- Don "Truck" Lewis Harris Semiconductor Internet: del@mlb.semi.harris.com PO Box 883 MS 62A-028 Phone: (407) 729-5205 Melbourne, FL 32901
karish@mindcraft.com (Chuck Karish) (03/07/91)
In article <6124@segue.segue.com> jim@segue.segue.com (Jim Balter) writes: >In article <19017@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>test(1) is the sick on. Any version of test(1) which relies on >>access(2) is broken. > >1) The fact that access does not provide an option to test the effective uid > is brain damage. access(2) has a very specific purpose. If test(1) uses access(2) to determine whether the current process has access to a particular file, it's misusing access(2). There is no system interface that simply and reliably provides the desired information. The advice of the 1003.1 committee is not to try to guess whether access would be granted based on the permission bits, but to actually try the function or utility and see what happens. This is somewhat unsatisfactory, but so is guessing, which can't possibly take into account the effects of extended ('alternate', 'additional') methods for determining file access (security levels, ACLs, etc.) It would be helpful if there were a second interface that could be used to check file access based on the effective UID. Adding a flag to access() at this point would not be an acceptable solution; it would break too much existing code. Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/07/91)
In article <668288533.3106@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: > There is no system interface that simply and reliably provides the > desired information. The advice of the 1003.1 committee is not to try > to guess whether access would be granted based on the permission bits, > but to actually try the function or utility and see what happens. One perfectly good solution would be to have an O_EXEC mode for open(), and allow fexec() upon files open for O_EXEC. This would not break anything, it would solve the race conditions and inaccuracies that plague access(), and it would fit comfortably into current systems. Too easy, huh? ---Dan
sef@kithrup.COM (Sean Eric Fagan) (03/07/91)
In article <668288533.3106@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >It would be helpful if there were a second interface that could be used >to check file access based on the effective UID. Adding a flag to >access() at this point would not be an acceptable solution; it would >break too much existing code. SCO has an eaccess which does exactly that. I just tried it, and it worked. (Actually, I had a fun few minutes, because it kept telling me that I had write permission to /etc/passwd without having to be root [I made my binary suid root]. If occurred to me, after a while, that the file was group writable, and, now that multiple groups work, I happen to be in the "correct" group to write to it. Neat...) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jfh@rpp386.cactus.org (John F Haugh II) (03/07/91)
In article <668288533.3106@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >It would be helpful if there were a second interface that could be used >to check file access based on the effective UID. Adding a flag to >access() at this point would not be an acceptable solution; it would >break too much existing code. IBM did exactly this with AIX v3. They have a system call, accessx(), which takes a flag as an additional parameter to determine who should be tested for. You can test for yourself as real id, yourself as effective id, some notion of "anyone", and some notion of "everyone". It does all the magic of checking for extended access control lists and so on. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
peter@ficc.ferranti.com (Peter da Silva) (03/08/91)
In article <1991Mar07.091123.13033@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > (Actually, I had a fun few minutes, because it kept telling me that I had > write permission to /etc/passwd without having to be root [I made my binary > suid root]. If occurred to me, after a while, that the file was group > writable, and, now that multiple groups work, I happen to be in the > "correct" group to write to it. Neat...) Isn't this a security hole? I mean, once you can write to the password file you have the keys to the kingdom. I hope this goes away when you turn off C2. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
sef@kithrup.COM (Sean Eric Fagan) (03/09/91)
In article <QMY9-24@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Isn't this a security hole? I mean, once you can write to the password file >you have the keys to the kingdom. I hope this goes away when you turn off C2. Eeek. Let me explain this a bit better: a while ago, I wrote up my own implementation of login that set multiple groups. I was running that. However, the *kernel* was still broken: it didn't check multiple groups for access permission (which kinda defeated the entire reason I'd done it: I wanted to be in group uucp so I didn't have to be root to do a 'cu -l tty2A dir'). Now, however, the kernel has been fixed, and a new version of login. I installed all of this, and went on my merry way. However, I'd *completely* forgotten that I'd set myself up to be in almost every group in existance (well, 7 of them, at least). One of those groups was 'auth', which has write access to /etc/passwd. Since the multiple groups now work, I have write access to /etc/passwd. And, no, sorry: under sco's unix, having write access to /etc/passwd will only allow you to lock everyone out by removing or changing values; it won't let you get it. You need to create one or two more files elsewhere in the tree with all the proper magic in them. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
peter@ficc.ferranti.com (Peter da Silva) (03/12/91)
In article <1991Mar08.194702.5369@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > And, no, sorry: under sco's unix, having write access to /etc/passwd will > only allow you to lock everyone out by removing or changing values; it won't > let you get it. You need to create one or two more files elsewhere in the > tree with all the proper magic in them. Does "auth" have write access to these files? If so then you haven't changed the problem any. Just made it more obscure. Nothing that someone with adb and a little determination couldn't crack. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
sef@kithrup.COM (Sean Eric Fagan) (03/12/91)
In article <S3+9E31@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Does "auth" have write access to these files? If so then you haven't changed >the problem any. Just made it more obscure. Nothing that someone with adb >and a little determination couldn't crack. As a matter of fact, the files are accessible to those who know where they are (assuming they are in group auth). Note, btw, that I don't think this is any more insecure than any other unix with multiple groups; you just don't put people in group auth 8-). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jfh@rpp386.cactus.org (John F Haugh II) (03/12/91)
In article <S3+9E31@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Does "auth" have write access to these files? If so then you haven't changed >the problem any. Just made it more obscure. Nothing that someone with adb >and a little determination couldn't crack. You have a pretty poor understanding of how systems with "enhanced security" work. More likely that not, "auth" is only able to write the various files when some magical "trusted path" exists, or only "trusted" applications can be executed by "auth" or some other restriction. You will likely find that "auth" lacks whatever magic cookie it is that would let any random program modify any random file. If it doesn't we should all point our fingers at SecureWare and laugh heartily. [Then we can point our fingers at OSF for picking SecureWare as well ;-) ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
tchrist@convex.COM (Tom Christiansen) (03/13/91)
From the keyboard of jfh@rpp386.cactus.org (John F Haugh II):
:In article <S3+9E31@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
:>Does "auth" have write access to these files? If so then you haven't changed
:>the problem any. Just made it more obscure. Nothing that someone with adb
:>and a little determination couldn't crack.
:
:You have a pretty poor understanding of how systems with "enhanced
:security" work. More likely that not, "auth" is only able to write
:the various files when some magical "trusted path" exists, or only
:"trusted" applications can be executed by "auth" or some other
:restriction. You will likely find that "auth" lacks whatever magic
:cookie it is that would let any random program modify any random
:file. If it doesn't we should all point our fingers at SecureWare
:and laugh heartily. [Then we can point our fingers at OSF for
:picking SecureWare as well ;-) ]
I maintain that both "auth" and "sysadmin" give you indirect
root privileges. With auth, you can create accounts or modify
existing ones. With sysadmin, you can mount arbitrary things
at arbitrary points, do dumps and restores etc. I'm sure you
see how both of these quickly allow you to do anything you want.
Secureware has only replaced one all-powerful account with
several all-minus-one-powerful accounts, and anyone with
6 months experience at UNIX knows how to add that one back in.
--tomjfh@rpp386.cactus.org (John F Haugh II) (03/13/91)
In article <1991Mar13.042033.12450@convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I maintain that both "auth" and "sysadmin" give you indirect >root privileges. With auth, you can create accounts or modify >existing ones. With sysadmin, you can mount arbitrary things >at arbitrary points, do dumps and restores etc. I'm sure you >see how both of these quickly allow you to do anything you want. >Secureware has only replaced one all-powerful account with >several all-minus-one-powerful accounts, and anyone with >6 months experience at UNIX knows how to add that one back in. No, I actually =don't= see how an understanding of =normal= UNIX implies that you can do anything in particular to an =abnormal= version of UNIX. Consider, just as an example, that I could implement the "mount" system call in such a way that any privileged commands on that volume wouldn't be treated as privileged until a privileged system utility had verified that the volume was in an acceptable state. So "sysadmin" lets you mount some disk - big deal. Perhaps "sysadmin" also lets you crash the machine by unmounting critical volumes or over-mounting others. A quick look at the audit logs will reveal what happened. And yes, if you can create privileged accounts (via "auth") then you can do anything you want - which is the purpose of a privileged account. True, but not very interesting since the goal is then to become "auth". If "sysadmin" somehow lets you become "auth", then you might have something there. If all "sysadmin" lets you do is make "sysadmin"-like mistakes on purpose, again, not very interesting. SecureWare, not being a formally evaluated product, probably has =many= little holes, and if this is one of them, point out how I can become "auth" with just access to "sysadmin" and then we can sit back and have a good laugh at SecureWare. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
peter@ficc.ferranti.com (Peter da Silva) (03/14/91)
In article <1991Mar12.102013.22527@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > As a matter of fact, the files are accessible to those who know where they > are (assuming they are in group auth). Note, btw, that I don't think this > is any more insecure than any other unix with multiple groups; you just > don't put people in group auth 8-). How about: ed - /etc/group << '!' g/auth/d w q ! Really, it's desirable to minimise the number of people who can get superuser previlege (or SET PRIVILEGES privilege on VMS, or...). This encourages admins to create more such users. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (03/16/91)
In article <19101@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <S3+9E31@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >Does "auth" have write access to these files? If so then you haven't changed > >the problem any. Just made it more obscure. Nothing that someone with adb > >and a little determination couldn't crack. > You have a pretty poor understanding of how systems with "enhanced > security" work. Maybe, maybe not, but at least I'm paying attention. John, "auth" is a *group*. Not a user. Anyone in group "auth" is effectively root. Sean has admitted as much. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
sef@kithrup.COM (Sean Eric Fagan) (03/18/91)
In article <TH0A5Y8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Maybe, maybe not, but at least I'm paying attention. John, "auth" is a >*group*. Not a user. Anyone in group "auth" is effectively root. Sean >has admitted as much. (Incidently, I just realized how much this has strayed away from the original topic. I think I will keep using trn 8-).) Yes, Sean admitted as much. However, Sean probably should point out that, initially, only two users are in group auth: root and auth. Sean deliberately put himself in group auth when creating his account, because he doesn't like su'ing all the time. As shipped, the system is no less secure, in that respect, than any other system. (Incidently, auth is a pseudouser; one is supposed to su to that account to do work. But I figure, why bother? 8-)) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jfh@rpp386.cactus.org (John F Haugh II) (03/18/91)
In article <TH0A5Y8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Maybe, maybe not, but at least I'm paying attention. John, "auth" is a >*group*. Not a user. Anyone in group "auth" is effectively root. Sean >has admitted as much. It was a generic statement, Peter. Just because you have access does not mean twiddling some bit works. And yes, in this specific case, giving someone access to the user files by putting them in the group which is permitted to modify user accounts would seem to let them modify user accounts, no? There are a number of BSD programs which act differently for group "wheel" than "staff" or whatever - and yes, you could probably even go from group "wheel" to UID 0 with a minimum of effort - but the solution is very, very, simple. Don't give the privileges away in the first place. Back to SCO UNIX, judging from the complaints regarding the obscurity of the SCO/SecureWare features, it appears that one collection of C2 criteria which were violated with this system are the ones involving system documentation. If, for example, "auth" is some giant hole that shouldn't be opened up except by the criminally insane, the "Trusted Facility Manual" should point out the risks associated with group "auth" in a secure environment, and the test documentation should outline how SCO and SecureWare tested the system to locate these deficiencies or verify that the security policy was correctly implemented. With a real C2 system we wouldn't be having this discussion (unless the testing didn't catch some exceptional conditions) since it would have been laid out in black and white in the documents the system came with. It's kind of like the difference between Brand-X re-runs and Nick-At-Nite brand re-runs ... -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
peter@ficc.ferranti.com (Peter da Silva) (03/19/91)
In article <1991Mar17.233804.9640@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > (Incidently, I just realized how much this has strayed away from the > original topic. I think I will keep using trn 8-).) Me too. Too bad mthreads core dumps on our little pre-SCO Xenix System III systems. Intel promised us SCO would be doing the support, but apparently that was their own little fantasy. Meanwhile I've been hacking TASS to make the commands more rn-like. It's a very nice little baby newsreader, with basic thread-following capability, and the threads databases are created on demand (it runs set-id to news, but properly gives up permissions in all the right places). -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"