ronald@robobar.co.uk (Ronald S H Khoo) (08/13/90)
[ Brandon, skip to the last paragraph, there's something there for you ] "Brandon S. Allbery KB8JRR/KT" <allbery@ncoast.ORG> made some very good points about Charley Watkin's letter on SCO Unix security which I hope Charley (with his SCO hat on) will take on board. I personally think that the problems with SCO Unix security go far further than Brandon's points (I think maybe he was a little too polite :-), and it does look like SCO has a fundamental misconception about what all the fuss is about. I'd like Charley to respond to the net both to Brandon's points and to a few more in addition. (Dion, can you make sure he sees both postings ? thanks, I owe you a beer :-) [ >| is Charley being quoted by Brandon, > alone is Brandon ] >| Yours is a >| natural reaction, I think, to the ongoing adaptation of the UNIX >| system to the needs of end-users. > Most end-users do not need security that, even in soi-disant "relaxed" mode, > is obtrusive. Furthermore: * My customer sites *do not* have enough disc space for all that crud. * I don't want to have to pay royalties to SecureWare Inc for "features"(+) I'm trying to turn off. * Many systems are NOT administered by the end-users. * Systems which operate as part of a much bigger system (like the ones we sell: the Unix is worth 0.1% of the system) often DON'T HAVE end-users in that sense. In addition: > Even in relaxed mode, the system screams bloody murder about authorizations > when I attempt to add a shell to the sysadmsh menu. Which I am trying to do > because you've managed to make it impossible to maintain the system in any > other way. This kind of thing plays complete havoc with any kind of automated maintenance scripts that people like Brandon or myself need to supply. IMHO the mistake SCO has made with SCO Unix is to assume that it will only be used in a narrow range of computing environments where the only way the system is set up and maintained is "by the book" by a local sysadm who has lots of time and little or no Unix experience. This will leave out * Sites which want to move their system to a 386 PC based Unix system from whatever they are currently running and have enough on their hands porting the application without having to replace all their administration scripts with a human and write lots of new procedures for a human to use instead of scripts. They might not have time, and probably can't afford the human. * Turnkey systems, posssibly supplied as part of a bigger system * Sites which need to have uniform maintenance over a variety of platforms * Sites which are maintained on a remote basis, with one sysadmin per 50 nearly identical sites (I'm one of these -- our customers DON'T HAVE sysadmins) The first point is most galling. It almost makes me think that this "security package" is some kind of Trade Union ruse to keep overmanning up. For goodness sake, computers are meant to save labour. > THIS I do not need. This my company does not need. I am close to > recommending we switch to 386/ix, and unless there are changes we will do so. And I would too, if not for the need to retain SCO Xenix compatibility, which I suppose I really have to trust SCO Unix best for. As soon as this is no longer necessary, SCO Unix will be re-evaluated with this point strongly to the fore. Brandon's not alone. In other words, here are reasons you'll lose new customers, and here are more reasons you'll lose existing customers. This will leave you with you lucrative US Government contracts, perhaps, but those come and go. You should treat that as icing on the cake, but remember that the rest of us are your bread and butter -- not as profitable, but consistently there. Think of the cash flow havoc you'd have if your base level business dropped further below your super-duper Govt contract work. Commercial sites normally don't need soft security, we normally operate with physical security. > An always-active authorization database on most > of the files in the system, however, is *not* useful under most circumstances; And consumes resource which I (or rather the customers) can't afford. >+--------------- >| incorporate C2 features, I think even the traditionalists among us >| will someday have to come to grips with the presence of C2 security. >+--------------- > Have you ever heard of an "off switch"? Actually, I think that'd be the wrong way round. An "on switch" to install it as a separate package would be far more sensible. Even more sensible would be to make that package unbundled. This is the only thing I ever want to see unbundled, by the way. You know how two wrongs make one right .... You could alternatively supply all programs which access the tcb database as partially linked objects (now that you've got the ldr working :-) and provide libSecure.a and libNormal.a (just stubs) and let us choose at system build time which version we want. I don't think many people will want the former. > Tradition be d*mned; I'm talking about systems that *work*, Here is another place where SCO have made a serious mis-assumption. They seem to have assumed that "tradition" is the only concern of Unix users. It's not simply for a veneer of "traditional" behaviour that we want to be able to do /bin/rm -f /tcb, remember that whole Unix way of doing things is by tying programs together in an ENVRONMENT. If you break this environment, people who only use integrated applications like MS-DOS users will be fine, but the rest of us will suffer (read: find another vendor) because OUR SYSTEMS WON'T WORK ANYMORE. You HAVE another product which is aimed at the vertical MS-DOS-type Integrated Systems market, it's called Open DeskTop. Can you leave the system builder's product alone, please ? Or possibly, sell a separate system builder's product ? If not, someone else will sell it. I haven't gone out of my way to be polite here, this is too important a subject to pussyfoot around with. I hope you appreciate my frankness, Charley, please don't take offence -- none is intended. > Assuming the !@#$%^&* authorization database doesn't throw screaming fits > at me, I'm going to replace the mail system with a fresh copy of mmdfIIb-43 > from louie.udel.edu. End of *that* problem. You too, Brandon? I wonder why ? :-) Be careful -- the src/uucp/rmail.c has incorrect arguments at update level 43, it should read (void) sprintf(subargs, "lvmti%s*k30*h", uchan); (+) feature, n., documented bug (q. v.) or other failing in a supplied system. -- UNIX is Registered TradeMark of ATT in the USA and other countries SCO is a TradeMark of the Santa Cruz Operation, Inc. MS-DOS and XENIX are TradeMarks of Microsoft Inc. Open DeskTop is a TradeMark of someone or other, it's SCO, I think. Flames to me by email, please. They will be summarised to the group. -- Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343 Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
jpp@specialix.co.uk (John Pettitt) (08/13/90)
Some comments on the C2 debate: We are running C2 SCO Unix here, in a traditional developemt environment (lots of users + several sysadm people with kernel skills). On the whole we have found C2 to be a waste of space because the sort of things we need are not there ! To explain further: a) The average commercial site does not need fancy logs that nobody is going to read. b) ditto subsystem authorizations. c) We DO NEED control over who can login on any terminal (I would like to limit modem access to authorized users). I used to be able to do this with a dialup passwd and SCO tok it out of the `secure UNIX' (I know it's back now). d) We DO NEED clear, automatic security reporting - We have scripts that mail the postmaster a list of all modem activity, bad su attempts (fails and attempts from users not on a valid list) etc etc. We had to write our own scripts to do this. We are not running imbedded system like Ronald, we have two of our internal systems running SCO Unix with 45 users between them. If anybody at SCO want's to take this further I will be at Forum next week. -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting !
root@edat.UUCP (Superuser) (08/14/90)
In article <1990Aug13.143157.12682@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: >Some comments on the C2 debate: > [deleted criticisms] SCO has stated that a whole new version of the C2 system is being released in the next update. I beleive this update is due out next week. In particular the management of C2 is expected to be much better. Maybe we should be wait until we get our updates to see how the new version is, AND THEN GUT THE SUCKER! (:-; -- Brian Douglass uunet!edat!brian
martin@mwtech.UUCP (Martin Weitzel) (08/15/90)
In article <165@edat.UUCP> root@edat.UUCP (Superuser) writes: >In article <1990Aug13.143157.12682@specialix.co.uk> jpp@specialix.co.uk (John Pettitt) writes: >>Some comments on the C2 debate: > >[deleted criticisms] > >SCO has stated that a whole new version of the C2 system is being >released in the next update. I beleive this update is due out >next week. In particular the management of C2 is expected to be >much better. To throw in another $ 0.02: Isn't one of the key principles of C2 security the following: SECURITY MUST NOT BE ACHIEVED BY OBSCURITY or in other words: Isn't any C2-secure system obliged to describe each and any method *how* their (until then only claimed) security is implemented? If I'm right with the above, I can not understand the whole discussion and the many complaints about SCO UNIX security features: 1) SCO does NOT document how C2 security is achieved. 2) The ones who complain haven't RTFM. If 1) is true, SCO shouldn't speak of their "C2-secure-UNIX", but of their "we-try-but-haven't-quite-managed-to-make-C2-secure-UNIX". If 2) is true, there's no reason to post any more complaints. (To those who didn't notice the sarcasm in my article until now: Of course you should continue to post your complaints, as a C2-secure system which documents its implementation in such a way that you can not find easily what you are looking for, may well be considered as one which trys to achieve security by obscurity and hence is *NOT* C2.) -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
tneff@bfmny0.BFM.COM (Tom Neff) (08/16/90)
In article <1990Aug16.174514.2646@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/KT) writes: >And you still haven't answered my biggest question: why do I have to put up >with this *at all* when the machines I have to install and maintain this on >need nothing more than simple group vectors and /etc/shadow? You don't. There are about five other 386 UNIX ports out there. I recommend anyone who doesn't want to get stuck with C2 security buy one of them. (They all run Xenix binaries nicely, by the way.) These messages asking "I think I want Unix for my 386, but does SCO sell it yet?" make me chuckle -- surely this is the sweetest coup in brand name recognition any value-added reseller ever pulled off... -- "The analytical Engine has no pretensions whatever |1+0-| Tom Neff to originate anything. It can do whatever we know |+0-1| tneff@bfmny0.BFM.COM how to order it to perform." -- Ada Lovelace, 1842 |0-1+| uunet!bfmny0!tneff
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/17/90)
As quoted from <881@mwtech.UUCP> by martin@mwtech.UUCP (Martin Weitzel): +--------------- | In article <165@edat.UUCP> root@edat.UUCP (Superuser) writes: | Isn't one of the key principles of C2 security the following: | | SECURITY MUST NOT BE ACHIEVED BY OBSCURITY | | or in other words: Isn't any C2-secure system obliged to describe | each and any method *how* their (until then only claimed) security | is implemented? +--------------- This obscurity isn't intended to enhance security; it's just SCO keeping its (l)users fat, dumb, and happy. I suspect the usual slaughter will follow at some point as well.... +--------------- | system which documents its implementation in such a way that you can | not find easily what you are looking for, may well be considered as | one which trys to achieve security by obscurity and hence is *NOT* | C2.) +--------------- The manuals in question didn't even come with my system. (grrr) And even with them, I have yet to find out how to do anything without writing a C program, to be run as root in order to have permissions to massage the authorizations database. And you still haven't answered my biggest question: why do I have to put up with this *at all* when the machines I have to install and maintain this on need nothing more than simple group vectors and /etc/shadow? ++Brandon -- Me: Brandon S. Allbery VHF: KB8JRR/KT on 220 (soon others) Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/18/90)
As quoted from <15759@bfmny0.BFM.COM> by tneff@bfmny0.BFM.COM (Tom Neff): +--------------- | In article <1990Aug16.174514.2646@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/KT) writes: | >And you still haven't answered my biggest question: why do I have to put up | >with this *at all* when the machines I have to install and maintain this on | >need nothing more than simple group vectors and /etc/shadow? | | You don't. There are about five other 386 UNIX ports out there. I | recommend anyone who doesn't want to get stuck with C2 security buy one | of them. (They all run Xenix binaries nicely, by the way.) These | messages asking "I think I want Unix for my 386, but does SCO sell it | yet?" make me chuckle -- surely this is the sweetest coup in brand name | recognition any value-added reseller ever pulled off... +--------------- Not my idea, unfortunately. The machine in question is an Altos 5000; it runs SCO Unix, but *not* the stock version: it has drivers for MultiDrop and Altos' serial port concentrators (based on past experience with Altos, they should be far more reliable than the norm for PC-class machines), the High Performance File Processor (optional attachment), built-in Ethernet controller and SCSI controller, etc. I *wish* I could just pick up 386/ix for it! I have conveyed my concerns to Altos, and they are at least partially aware that I usually have a pretty good idea of where I'm coming from. They seem receptive; we'll see what happens, whether it be changes to SCO Unix (doubtful) or a switch to 386/ix, or (worst case) being told there's nothing to be done about it. The latter may cause me to recommend that we start outfitting the Dell PCs with 386/ix... Dell may not understand the stuff, but *I* do. ++Brandon -- Me: Brandon S. Allbery VHF: KB8JRR/KT on 220 (soon others) Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR
richard@pegasus.com (Richard Foulk) (08/20/90)
>Not my idea, unfortunately. The machine in question is an Altos 5000; it runs >SCO Unix, but *not* the stock version: it has drivers for MultiDrop and Altos' >serial port concentrators (based on past experience with Altos, they should be >far more reliable than the norm for PC-class machines), the High Performance >File Processor (optional attachment), built-in Ethernet controller and SCSI >controller, etc. I *wish* I could just pick up 386/ix for it! I sounds like the Altos hardware has enough strikes against it to condemn its selection, just like SCO Unix on the software side. Remember, popularity is important when selecting hardware and software. Isn't that why most of us here have selected the 386-ATbus platform? It keeps the cost down and the alternatives up. -- Richard Foulk richard@pegasus.com
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/21/90)
As quoted from <1990Aug19.214500.18612@pegasus.com> by richard@pegasus.com (Richard Foulk): +--------------- | >Not my idea, unfortunately. The machine in question is an Altos 5000; it runs | >SCO Unix, but *not* the stock version: it has drivers for MultiDrop and Altos' | >serial port concentrators (based on past experience with Altos, they should be | >far more reliable than the norm for PC-class machines), the High Performance | >File Processor (optional attachment), built-in Ethernet controller and SCSI | >controller, etc. I *wish* I could just pick up 386/ix for it! | | I sounds like the Altos hardware has enough strikes against it to condemn | its selection, just like SCO Unix on the software side. | | Remember, popularity is important when selecting hardware and software. | Isn't that why most of us here have selected the 386-ATbus platform? It | keeps the cost down and the alternatives up. +--------------- I probably *should* refrain from comment, being that I work for an Altos VAR. On the other hand, I stay very definitely *out* of sales, so I'll risk it. In any case, just from a technical standpoint, there are a number of comments I can make: (1) Nothing stops you from linking in your own SCSI or serial drivers and using your own cards. But from my own experiences, both with the PC line we also carry and from trying to make ncoast work, SCSI/ESDI is variable in quality and serial port cards/drivers are pretty much all problematic. (2) If you're running other kinds of boards, they will work fine; the 5000 is an EISA machine. From a technical standpoint, I liked the 2086/3086/2000 bus much better, but it was proprietary and is now kaputt, since all the machines have been dropped. (The 3068 series uses it as well, but it has never been a big seller except in the Pick marker, which we don't deal with.) So far, the hardware seems OK, and in fact quite nice; I wish I had the HPFP version to play with, since it should make our disk-bound database applications *really* scream. But time (and the market) will tell. I did see that Unix/World, at least, seemed to like it, not that that means anything. I'd just like to be able to avoid e.g. 6 months+ of trying to make various port boards work on ncoast and a month trying to get a Digiboard working on a Dell (for one of our competitors, no less; punishment detail? ;-) The MDC/2 hasn't faulted me yet, whereas ncoast *still* has modem/port problems. And RS-232 is one of the few hardware areas that I've worked with ever since I got into this racket. All of which does *not* mean that if the software problems aren't resolved, I won't start pushing for us to switch to a different brand... I expect both the hardware and the software to work reasonably well. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR/KT on 220, 2m, 440 Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR