| |||||||||||||
|
| |||||||||||||
Rackable Systems acquires SGIRackable Systems acquires SGIPosted Apr 1, 2009 18:49 UTC (Wed) by kent (subscriber, #3834)In reply to: Rackable Systems acquires SGI by ajross Parent article: Rackable Systems acquires SGI
Yes, no other vendor could come up with so hilarious
security holes as SGI. Irix, we miss you.
Or not.
(Log in to post comments)
Rackable Systems acquires SGI Posted Apr 1, 2009 18:55 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Any history there? The only really obvious security hole in Irix was the fam stuff --- and wasn't that just an information disclosure vulnerability (you could monitor files you couldn't normally read or even know exist.)
Rackable Systems acquires SGI Posted Apr 1, 2009 19:14 UTC (Wed) by kent (subscriber, #3834) [Link]
Irix was famous for having default accounts installed without password,
e.g. "lp".
See http://www.cert.org/advisories/CA-1995-15.html
Irix also holds the world record for lowest TCP port number
http://www.cert.org/incident_notes/IN-98.01.irix.html
Rackable Systems acquires SGI Posted Apr 1, 2009 23:53 UTC (Wed) by jd (guest, #26381) [Link]
On the other hand, Trusted Irix was supposed to be one of the better secure OS'. I forget where it came in relationship to Trusted Solaris, but both were B-rated systems. (The only A-rated general-purpose OS I know of was Genesis. The others were all special-purpose.)
Rackable Systems acquires SGI Posted Apr 2, 2009 11:22 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
This is an Apple / Orange comparison
The A and B ratings you're talking about don't involve actual security, but only certifying to a standard. It is perfectly possible to have gaping holes in your system's security, so long as the design document doesn't call enough attention to them for the audit to notice.
A conscientious developer would obviously want to not only meet the requirements of the standard but also build a system that was secure in practice. But not everyone is conscientious, and those who are may find that they have too few resources and the business prioritises the certification.
As an example, it is not uncommon to find that you can meet the requirements by writing "After installation, the following four pages of instructions must be followed in order to set and enable the access password". The auditors will follow the steps, and sure enough they work. But unfortunately 99% of real world installs will not have these complex steps followed and will remain insecure.
Or you may decide that some of the requirements impose onerous restrictions on development systems, so you provide a simple dip switch which disables key security features. Certified systems have the dip switch unset, but it's shipped set for the convenience of development and testing staff and nobody changes it unless they're explicitly told to do so on a production machine. Even support engineers may set it, and forget to put it back. So in practice again 99% of real world systems are insecure.
Rainbow Books & Security Posted Apr 3, 2009 0:20 UTC (Fri) by jjs (guest, #10315) [Link]
Actually, at the B & A levels, it was (now they use the Common Criteria) far more than just "audit" (see the books at http://csrc.nist.gov/publications/secpubs/rainbow/ - in particular http://csrc.nist.gov/publications/secpubs/rainbow/std001.txt). The included proving the system, and testing for holes such as covert channels.
Rackable Systems acquires SGI Posted Apr 2, 2009 13:54 UTC (Thu) by ghamlin (guest, #57789) [Link]
Yes, lots of history there.
Irix had many fine qualities. SGI packaging sensibilities were actually somewhat similar to Redhat in many ways. Most commerical Unixes shipped aweful configuration files. Linux was always better here, IMO. Irix was above average.
However, for all its features. Irix had the worst security of an Unix I can think of.
SUID executables that don't set PATH. 'EZsetup' accounts that were easy to leave enabled by accident. Other odd accounts with default passwords for 'demo software'.
SysV style 'chown give-away' worked. So if you could create a file somewhere you could set the permission and then give it to a user. This leads to all sort of bizarre vulnerabilities when utilities check to see if the file's ownership and permissions are safe before trusting its contents.
However, Irix could be secured. The OS was fairly decent. They just made it a challenge. Basically don't trust anything they wrote with SUID. Remove all their cronjobs and wonder what bizzare 'feature' you broke. :)
They did have some nice features... GL, FAM, XFS. They would periodically show off and set new IO records with their architecture, but they also some fancy techniques to set records that were a bit dodgy that have not been ported elsewhere. (I vaguely recall it was possible to do device-to-device DMA transfers for example)
Really, SGIs were just nice machines not everything they did was polished, but the systems were pleasant and shiny. They have never been smart on the business side however. They failed over and over again. The visual workstations were a failure. They were hurt by the Itanium failure. I was pleased with their Linux work, but I lost a lot of respect for them when they stripped Cray of the T3E and killed that product rather than allow a much cheaper HPC solution to exist. They were not the most common machines to compile software on. Sometimes I would see messages from build scripts like 'Holy crap that worked send me an email at ...' when I would finish building things.
* chown give-away mean root privilege is not require to assign ownership to someone else for example:
$ touch my_gift_to_you
|
|
||||||||||||