...and taken a step that UNIX style operating systems have needed for quite some time....although it's not really something new - privilege controls have been implemented in some special kind of Unix OSs years ago (for example, Trusted Solaris) - not as a syscall-trace-daemon, but directly built into the OS kernel.
Some other OSs have always had privilege controls - for example, VMS and OS/400.
I always told people that standard unices should have such a privilege model, and I always wondered why noone knew about these privilege concepts.
This is a wonderful step in the evoluction of security that ALL of *BSD/Linux/etc. should implement without delay.
However, I'd prefer a kernel-based solution over the syscall-trace daemon; i guess this would also be faster
At least from an administrator's perspective, I think this should be the norm.
The simple UNIX privilege system is good: when programmers write code that runs as root, they know exactly what that code can do: everything.
This does not mean, that the privilege system is good - it just means, that the privilege system is very simple.
However, then we'd have to say that Windows 98 is better than unix, because there is no security at all, and so programmers don't need to think about privileges anyway..
programmers seem to have trouble understanding all the implications of all the different bits
This is not an operating system problem; However, privileges are commonly granted to binaries by the administrator/ISSO, not by programmers.
And they try to take appropriate care.
Yes, they try, and they fail frequently, that's why we have buffer overflows in applications
This is the first real kernel-level security feature in OpenBSD.
Earlier versions of OpenBSD had only application-level security (secure applications, but running as root, and therefore no effective OS-level security below the application-level).
Granting certain privileges to an application instead of all-powerful superuser-privileges is IMO the most-important security feature of a secure operating system - this is a standard feature on every trusted unix system, and actually i believe it should be a standard feature on every unix platform.
When Microsoft compares Windows Security with Linux/Unix security, they commonly show you all the cute security features of Windows 2000 and then compare it with a freshly installed Red Hat 7 box (or something like that, debian, SuSE, whatever you want).
What about comparing the most secure setup of Windows with the most secure setup of Linux or Unix?
Now you end up comparing Windows 2000 with HP SecureLinux or with Trusted Solaris, Trusted Irix, and so on.
The most secure setup of Windows 2000 has C2 level security (discretionary access controls capable of defining access to the granularity of a single user, audit trail), while the most secure Versions of Linux have things like domain based access controls (however they are not certified at any TCSEC security level, not even C2) and the most secure Unix environments have B3 level security (structured protection, zero design flaws and minimum implementation flaws).
Just take a look at how security mechanisms work, maybe compare Linux+Pitbull/LX (domain based access control) with the most secure Version of Windows 2000 - and try to imagine, how DBAC keeps your computer secure, even when somebody hacks your sendmail daemon.
Now go and look for a Version of Windows with zero design flaws, or maybe just a B1 secure Version of Windows, good luck.
regards, octogen
Some further information: Trusted Solaris, Sun Microsystems; ITSEC EAL4 (exceeding B1 security); Pitbull, Pitbull/LX, Argus Systems; ITSEC EAL4 security for AIX and Solaris; Domain Based Access Control for Linux (Pitbull/LX); XTS/300, Getronics; TCSEC B3; Firewall Server, BorderWare; (Unix based Firewall), ITSEC EAL4 with EAL5 vulnerability analysis; Windows XP, Microsoft; TCSEC C2;
An Operating System should of course not be affected by a worm which exploits a bug in a webserver daemon.
However, an Operating System can not prevent a worm from exploiting a bug in an application, but it should be able to prevent an application (and even a hacked application) from taking over the operating system or other applications on the same computer.
That's simply set noexec_user_stack=1 in/etc/system on Solaris/SPARC.
However, Intel processors are not capable of marking a stack segment read/write. The Write/Exec Flags share one bit in the descriptor, so you can't mark stack pages as nonexecutable if you want to have write permission to the same page.
$ cd OpenSSL $ (for obj in $(find . -name *.c); do grep strcpy $obj; done) | wc
37 72 1197 $ (for obj in $(find . -name *.c); do grep strcat $obj; done) | wc
47 57 1125 $ (for obj in $(find . -name *.c); do grep goto $obj; done) | wc
2840 10161 71668 $
Most of the "goto"s are something like "goto end" or "goto bad". However, things like "goto start" look as if they could have been done using for(;;) { } or do { } while(..) or something similar instead.
I wonder why everyone uses null-terminated character arrays and dangerous things like strcat() or strcpy(). Maybe one should rather use a collection of 'trusted' functions that keep track of the current lenght and the maximum lenght of a character array; just for the case one would like to call a product "secure".
OpenVMS can not identify data which came Buffer overflows, and therefore, OpenVMS can also be exploited via buffer overflows - this can be prooved by writing just a few lines of C code.
The only difference to many other OSs is, that applications do not have more privileges than are required to run the application, while on Linux for example many applications (like Sendmail or FTP-Servers) have Superuser-privileges, and therefore can override Discretionary Access Control.
I am almost absolutely sure, that it is possible to also run arbitrary code by exploiting buffer overflows on OpenVMS. But even if you could not, you can still modify data and pointert - that's enough to compromise security of a privileged program.
There are also Unix operating systems which have a privilege model, and some of them have got a much more fine grained privilege model than OpenVMS *PLUS* Trusted Computing Base Controls, File Security Flags and many other things.
So OpenVMS is by far not the most secure OS - personally, I think even OS/400 is more secure, because of its object-based design and its type-enforcment policies.
Oops, I got something wrong in the original post...
Windows 2000 WITHOUT Norton's Firewall had an nmap rating of ~ 12000, Windows 2000 WITH the Firewall achieved the better rating of course, approximately 15000.
...mostly because OpenVMS people tend to think, that 'their' OS is the most secure one on this planet (just like OpenBSD developers do, too).
Compared to Standard-Unices, OpenVMS might offer superior security, mostly because of the privilege model it utilizes instead of giving all-powerful root privileges to many user space applications.
On the other hand, we've got OSs which have much more sophisticated security than OpenVMS. First, there is IBM's AS/400, which has got a privilege model quite similar in extent to the one used in OpenVMS, but additionally it has object-based design, and therefore object-based security (type enforcement and such...). However, it lacks Mandatory Access Control, TCB, Trusted Path and some other things mostly required by military and/or government environments, and therefore it only achieves a C2 security rating. And then there are a couple of really secure Trusted Unices/Unix-style OSs, like Trusted Solaris, the Pitbull Addon for Solaris and AIX, Trusted IRIX, or XTS/400. Just talking about fine-grained privilege controls: Argus' Pitbull has got around 100 privileges, how many privileges are there on an OpenVMS box?
No OS has ever received an A1 security branding. And the only OS which has ever received a B3 security branding, is actually a Trusted Unix Environment, something like a Unix clone with some proprietary security mechanisms built into the kernel (OpenVMS was B1 or maybe B2, iirc).
---
Regarding secure TCP/IP initial sequence number generation, it does not take a Trusted OS to just generate secure sequence numbers.
About two months ago, I compared initial sequence number generation on the following OSs using nmap: * Windows 95 * Windows ME * Linux 2.2.x * Windows 2000 (plain) * Windows 2000 (with Norton Internet security installed) * OS/2 Warp Server Advanced 4.0 (default install) * Sun Solaris 7 x86 (with tcp_strong_iss set to 2)
The results where pretty interesting and also a bit surprising: Windows 95 was worst (ok, that's not surprising;-), nmap rating ~10 Then came OS/2, which was not much better, nmap rating ~ 1000 (BTW: does anyone have nmap results from OS/390 or OS/400?) Even Windows ME was a bit better than OS/2, but still far away from being secure, nmap rating ~ 8000 There was little difference between Win2k with Norton's Firewall (~12000) and Win2k without the Firewall (~15000) Linux' results were quite good, nmap rating approximately some hundred-thousands or millions Solaris with tcp_strong_iss set to 2 seemed to offer really strong sequence number generation, so nmap just printed a lot of 9s
---
Additional information: Here is nmap. Here is Argus Systems (EAL4 security for Solaris/AIX) Here is IBM's AS/400 Here is Getronics (B3 secure Unix Environment running Unix and Linux applications) And finally, here is OpenVMS
We always call time the 4th dimension, so this may be the reason for many of us to believe, that we can simply move something around on the "time line" - just like moving your mouse around on your desk, changing it's x/y/z coordinates.
But time is somehow different, it's more like a result of everything that happens.
Traveling through time on one specific place (not everywhere) would just be like one object in 3-dimensional space which has got 2 x-coordinates, but only 1 y- and 1 z-coordinate.
Doesn't look like we will ever be able to travel through time. We are just constructing too complex solutions around very simple facts, and everything looks right, when it actually isn't, because we do not have enough knowledge to prove our theories. It's always just one theory built on (or proven by) another theory...
An unsecure application running on a Mac makes the Mac even more vulnerable than most other Operating Systems, because under Mac OS every application has full access to all system resources (Mac OS does not have multiuser security).
Instead, if you run a webserver, which is secure to run on a Mac, on Linux or something else (whatever you want), and that webserver does not have security bugs, then any other operating system is even more secure than your Mac, because other operating systems have multiuser security, additionally to the secure webserver.
Mac OS is not a secure OS - maybe you are running a secure webserver on top of the unsecure Mac OS, but then you are talking about the wrong thing, because the webserver does not have anything to do with OS security.
There are *much* more secure operating systems than Mac OS. Most of them would have been able to stop an attacker, who just exploiting a third-party Addon application, because these OSes do not depend on application level security.
Take a look about XTS-400 from Getronics, Pitbull from Argus Systems, Trusted Solaris from Sun or OS/400 from IBM to understand, how real security works (EVEN IF your application gets hacked).
Mac OS is not suitable as a server OS, because it does neither have protected memory nor preemptive multitasking. Mac OS X might be suitable as a server, but I think it is mainly meant to be a workstation OS.
regards, octogen
And, by the way, SecureOS from Secure Computing has NEVER been hacked, Argus Pitbull on AIX and on Solaris/SPARC have NEVER been hacked (and only once on Solaris/Intel, Sun's fault, not Argus'), Getronics XTS-400 has NEVER been hacked - although those OSes where running a lot of *insecure* third-party addons.
So please, don't pretend that Mac OS is secure, if you can't prove it.
At least an authorizations/privilege security model instead of the anyone/root distinction is absolutely necessary.
The problem is, that many daemons (like Sendmail and such) override *all* security - of course, this is absolutely unnecessary. For example, on Argus enhanced systems you run Sendmail with the pv_asn_port privilege instead of root privileges. If someone manages to hack Sendmail, then the attacker can do nothing else than just open port 25, while on other OSs (even OpenBSD) the attacker gains root privileges. Sendmail does not need root privileges to run, so why should we give Sendmail root privileges?
One key to more security is the 'principle of least privilege'. Modern Unix Operating Systems like Trusted Solaris show, that it is possible to implement fine-grained privilege control in Unix kernels.
Just securing a few dozens of applications (that's what the OpenBSD project calls OS security?) is not enough. What if I need to run some other application?
An Operating System should be able to protect data even in the case, that an application gets hacked.
Our real problem is 'root' - it should never be used for any kind of server application (daemon), but only for system administration by an authorized user. There should not be any permanent processes running as root.
LIDS, the grsec patch, NSA's sample implementation of MAC and such things are steps into the right direction.
The worst problem regarding security is probably the fact, that today's mainstream processors mix up code, data and adresses in memory without being able to distinguish between these categories.
You can put anything (even some characters of input from the keyboard) into memory and let the computer use it as a memory address - and this is really a very, very bad architecture.
If an attacker could only modify data by exploiting buffer overflows instead of being able to put additional code on your machine and to execute it, his or her possibilities would be much more limited.
Most secure operating systems can't prevent a security breech within an application, but are still able to prevent access to the OS itself, to other applications or to sensitive data. This is done by strictly following the 'principle of least privilege', which mainly means that you do not run any process with all-powerful root privileges. (Take a look at Argus' homepage for more information about secure Unix kernels with authorizations/privileges instead of 'root')
IBM invented a technology which would be suitable for protecting the system from unintentionally modified addresses, almost 20 years ago (in the System/38).
We definately need better processors and better operating systems.
A short summary of methods to prevent from buffer overflow exploitation: * If a process CALLs a subroutine, the return addresses shall become pushed onto the stack and marked as a 'valid address' in some kind of shadow memory (if you have 64bit long addresses, you need 128MB additional memory as the shadow RAM for each 1024MB RAM). * If some piece of data is MOVed to memory, then the memory region shall become marked as 'non-valid address' in shadow memory. * If a processor tries to fetch an address from a memory region which is not marked as 'valid address' then the processor shall raise an exception (interrupt) to inform the operating system about the invalid pointer. * Shadow memory shall only be accessible from the highest privilege level (that is, from kernel mode) * User mode processes shall not be able to use OS APIs in order to mark modified addresses as 'valid address' unless the user process has the privilege to use the API. * There should be a privilege which causes the OS to ignore invalid pointers and resume execution of a user process, in order to ensure that even very old programs (which use pointer manipulation without correct casting, etc.) can be used.
Unfortunately, there is almost no information on the net about hardware pointer protection, so you will possibly need to look into Frank Soltis' book "Inside the AS/400" to get very detailed information.
The question is not whether *BSDs are dying, but rather whether S/390s are dying.
Unix machines have had more processing power than S/390s for years now, but they did commonly not support block-mode terminals (like S/390's 3270), and therefore it was difficult to implement host-/terminal-based applications on unix-systems without causing too much network traffic.
AS/400's (aka iSeries 400) have got 5250-terminals, which are quite the same as the 3270's, but a few years ago AS/400's did not have as much processing power and/or disk capacity as mainframes. Recent AS/400's are mainly based on pSeries-like hardware, with the same powerful POWER4 processors, lots of cache memory and lots of main storage (RAM).
Since the biggest AS/400s are now more powerful than the biggest z/900 but also are more mainframe-like than the pSeries, it could be possible, that IBM is going to replace the S/390's with the more modern AS/400's.
Mozilla got a beautiful new GUI, skins, a few more functions, useless things like annoying "do you want to save this password?" messages which can't be turned off and such...
The final result is, that it is still very unstable (better than Netscape 4.7, of course) and relatively unreliable (often destroys its configuration files).
Why did Mozilla's developers spend all their time implementing useless things like skins instead of fixing the REAL problems? I think they could have done a much better job.
Another problem with Mozilla is, that it is extremly slow - especially in 8bit color mode (it renders everything with Steinberg dithering or something like that). Display complex websites can produce as much as 10 seconds full load on an SMP machine until the page gets displayed - while Netscape 4.7 displays the page instantly.
However, I will not use Internet Explorer instead - there are a lot of reasons why I do not like IE, including that it's rather insecure and that I do not like its chaotic User Interface.
Opera seems to be quite good, as long as websites are not too comlex (and I don't like these complex flash-javascript-dhtml pages, either). Reading/posting articles in Slashdot works fine.
Why can't Mozilla simply be faster and more stable?
If people can't get music from audiogalaxy, they will probably rather try to get an illegal copy of the whole album - in even better quality than the mp3 files on AG.
If then they can't copy the CD, they will hardly buy it just because they can't copy it.
Doesn't look like the RIAA is solving any problems!?
If they wanted a cluster, they would rather use a cluster of 32-way POWER4 machines (p690). These big irons scale much better than SMP Athlons and have faster RAMs and Bus systems. Finally, they're much more reliable than PC hardware.
These SX-* Systems are Vector Processor Machines. You need special programming techniques and compilers to make use of their peak processing power.
If you have to run applications, where you can not make much use of vectorized instructions, then these systems are not faster than any other computer is, too.
There are two american companies which are developing very impressive technologies:
Starbridge systems tries to make processors much more efficient, thus providing more processing power on less space. They make use of FPGAs (Field Programmable Gate Arrays), a lot of simple and stupid chips which can be reconfigured a couple of thousand times to run a combination of instructions most efficiently.
IBM is developing as much as three interesting technologies simultaneously:
- IBM tries to build hypercomputers (quantum computers), and research results look pretty promising. - a few images
- They are going to build a One-Petaflop Supercomputer until 2005 utilizing 1,048,576 Processors (32 Cores per Chip, 64 CPUs per Board, 8 Boards per Frame, in 64 Frames) - Blue Gene Project
- They are developing CPU Cores, where all execution units are connected asynchronously - that makes it easy to reach an extremly high clock frequency.
Speed per processor doesn't matter - just think about Intel SMP systems compared to RISC SMPs.
Scalability is the one thing that matters in supercomputer technology.
Drop me a mail, and I will give you a prove, that Mac OS 9 is at least as vulnerable as any other platform is, too.
I think, you should distinguish between Operating System Security and Secure Applications on top of an insecure OS.
Mac OS 9 does not have any security.
It's only the webserver which was secure. Use the same webserver on Linux, and Linux is as secure as your Mac.
This level of security can be reachen on ANY platform, including DOS and even Windows 95.
Just disable everything which has something to do with networking, and then install some secure server application.
I'd like to see a Mac OS 9 driven computer that can prevent hackers from destroying data DESPITE the fact that it is running insecure software - THIS would be real OS security.
NSA SELinux is (currently) not meant to be a secure Linux distribution. It's rather something like a "Demo"-Implementation of MAC in the Linux-Kernel.
Quotes: NSA SE-Linux FAQ 13.Is it secure?
[...] Put another way, "secure system" means safe enough to protect some real world information from some real world adversary that the information owner and/or user care about. Security-enhanced Linux is only a research prototype that is intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely to meet any interesting definition of secure system. [...]
16.Did you try to fix any vulnerabilities?
No, we did not look for or find any vulnerabilities in the course of our work. We only changed enough to add our new mechanisms.
Would be interesting to see Gary Kasparov play against an off-the-shelf SMP server...
I am almost sure that you do not need a supercomputer to beat human chess players today - something like a p690 or a Fire 15k should have enough cpu power to win most chess games.
Actually, Windows' privilege model is quite ineffective. Many privileges control the LAN-Manager, not the OS Kernel itself (eg. "Create permanently shared objects")
There are privileges like "Control Auditing" - but there is nothing like "allow this process to only ADD audit records to audit files" or "allow this process to only READ audit files". There is also nothing like "Allow restricted IOCTL calls", "Allow mount/umount".
Windows grants all privileges to users, not to the binaries in the file system. A process can not spawn a more privileged subprocess, because Windows does neither support setuid/setgid, nor does it suppport privilege sets for programs in Windows' file system. All these facts make the Windows privilege concept rather ineffective.
There are _much_ better concepts than the ones found in Windows - maybe take a look at IBM's OS/400, or at Argus Systems' Pitbull Foundation, which implements an even stronger Privileges/Authorizations concept.
On an Argus box, you could, for example, add the PV_FS_MOUNT privilege to the authorized privilege set of some new mount tool binary on your harddisk, and then add the MOUNT authorization to the privileged authorization set of the same binary. (Maybe set FSF_EPS if the program does not know how to handle privileges)
When a user executes the binary, the operating system would only put the PV_FS_MOUNT privilege into the effective privilege set of the spawned process, if the executing user has the MOUNT authorization (and if the PV_FS_MOUNT privilege is in the limiting privilege set of the process, which execs the binary - commonly the user's shell). A user without MOUNT authorization could now display a list of all mounted file systems, but he/she could not mount or unmount Filesystems. Even a user WITH MOUNT authorization could not mount/unmount file systems, if his/her limiting privilege set has been downgraded and for this reason does not contain the PV_FS_MOUNT privilege any longer.
---
YES, we NEED more powerful privilege concepts in Linux (and in ALL other Standard UNIX systems as well), to protect the OS from privileged daemons which get hacked for some reason. (And this is also the reason why OpenBSD ist NOT really a secure OS - it highly depends on the fact, that only bug-free daemons have root privileges. A really secure OS would not grant any daemon something which is as powerful as root privileges just to open a privileged port or to use some funny special system calls)
Currently, only Trusted Unices offer strong security - however, most users do not need labeled information security (as defined by TCSEC B1), which is rather difficult to administer.
There should be some "light" version of a Trusted Unix OS without Mandatory Access Control (and maybe with a more simple set of privilege) for normal users.
Slashdot Mirror
...and taken a step that UNIX style operating systems have needed for quite some time. ...although it's not really something new - privilege controls have been implemented in some special kind of Unix OSs years ago (for example, Trusted Solaris) - not as a syscall-trace-daemon, but directly built into the OS kernel.
Some other OSs have always had privilege controls - for example, VMS and OS/400.
I always told people that standard unices should have such a privilege model, and I always wondered why noone knew about these privilege concepts.
This is a wonderful step in the evoluction of security that ALL of *BSD/Linux/etc. should implement without delay.
However, I'd prefer a kernel-based solution over the syscall-trace daemon; i guess this would also be faster
At least from an administrator's perspective, I think this should be the norm.
That is true, nothing to add.
The simple UNIX privilege system is good: when programmers write code that runs as root, they know exactly what that code can do: everything.
This does not mean, that the privilege system is good - it just means, that the privilege system is very simple.
However, then we'd have to say that Windows 98 is better than unix, because there is no security at all, and so programmers don't need to think about privileges anyway..
programmers seem to have trouble understanding all the implications of all the different bits
This is not an operating system problem;
However, privileges are commonly granted to binaries by the administrator/ISSO, not by programmers.
And they try to take appropriate care.
Yes, they try, and they fail frequently, that's why we have buffer overflows in applications
This is the first real kernel-level security feature in OpenBSD.
Earlier versions of OpenBSD had only application-level security (secure applications, but running as root, and therefore no effective OS-level security below the application-level).
Granting certain privileges to an application instead of all-powerful superuser-privileges is IMO the most-important security feature of a secure operating system - this is a standard feature on every trusted unix system, and actually i believe it should be a standard feature on every unix platform.
When Microsoft compares Windows Security with Linux/Unix security, they commonly show you all the cute security features of Windows 2000 and then compare it with a freshly installed Red Hat 7 box (or something like that, debian, SuSE, whatever you want).
What about comparing the most secure setup of Windows with the most secure setup of Linux or Unix?
Now you end up comparing Windows 2000 with HP SecureLinux or with Trusted Solaris, Trusted Irix, and so on.
The most secure setup of Windows 2000 has C2 level security (discretionary access controls capable of defining access to the granularity of a single user, audit trail), while the most secure Versions of Linux have things like domain based access controls (however they are not certified at any TCSEC security level, not even C2) and the most secure Unix environments have B3 level security (structured protection, zero design flaws and minimum implementation flaws).
Just take a look at how security mechanisms work, maybe compare Linux+Pitbull/LX (domain based access control) with the most secure Version of Windows 2000 - and try to imagine, how DBAC keeps your computer secure, even when somebody hacks your sendmail daemon.
Now go and look for a Version of Windows with zero design flaws, or maybe just a B1 secure Version of Windows, good luck.
regards,
octogen
Some further information:
Trusted Solaris, Sun Microsystems; ITSEC EAL4 (exceeding B1 security);
Pitbull, Pitbull/LX, Argus Systems; ITSEC EAL4 security for AIX and Solaris; Domain Based Access Control for Linux (Pitbull/LX);
XTS/300, Getronics; TCSEC B3;
Firewall Server, BorderWare; (Unix based Firewall), ITSEC EAL4 with EAL5 vulnerability analysis;
Windows XP, Microsoft; TCSEC C2;
An Operating System should of course not be affected by a worm which exploits a bug in a webserver daemon.
However, an Operating System can not prevent a worm from exploiting a bug in an application, but it should be able to prevent an application (and even a hacked application) from taking over the operating system or other applications on the same computer.
That's simply set noexec_user_stack=1 in /etc/system on Solaris/SPARC.
However, Intel processors are not capable of marking a stack segment read/write. The Write/Exec Flags share one bit in the descriptor, so you can't mark stack pages as nonexecutable if you want to have write permission to the same page.
$ cd OpenSSL
$ (for obj in $(find . -name *.c); do grep strcpy $obj; done) | wc
37 72 1197
$ (for obj in $(find . -name *.c); do grep strcat $obj; done) | wc
47 57 1125
$ (for obj in $(find . -name *.c); do grep goto $obj; done) | wc
2840 10161 71668
$
Most of the "goto"s are something like "goto end" or "goto bad". However, things like "goto start" look as if they could have been done using for(;;) { } or do { } while(..) or something similar instead.
I wonder why everyone uses null-terminated character arrays and dangerous things like strcat() or strcpy(). Maybe one should rather use a collection of 'trusted' functions that keep track of the current lenght and the maximum lenght of a character array; just for the case one would like to call a product "secure".
OpenVMS can not identify data which came Buffer overflows, and therefore, OpenVMS can also be exploited via buffer overflows - this can be prooved by writing just a few lines of C code.
The only difference to many other OSs is, that applications do not have more privileges than are required to run the application, while on Linux for example many applications (like Sendmail or FTP-Servers) have Superuser-privileges, and therefore can override Discretionary Access Control.
I am almost absolutely sure, that it is possible to also run arbitrary code by exploiting buffer overflows on OpenVMS. But even if you could not, you can still modify data and pointert - that's enough to compromise security of a privileged program.
There are also Unix operating systems which have a privilege model, and some of them have got a much more fine grained privilege model than OpenVMS *PLUS* Trusted Computing Base Controls, File Security Flags and many other things.
So OpenVMS is by far not the most secure OS - personally, I think even OS/400 is more secure, because of its object-based design and its type-enforcment policies.
Oops, I got something wrong in the original post...
Windows 2000 WITHOUT Norton's Firewall had an nmap rating of ~ 12000, Windows 2000 WITH the Firewall achieved the better rating of course, approximately 15000.
...mostly because OpenVMS people tend to think, that 'their' OS is the most secure one on this planet (just like OpenBSD developers do, too).
;-), nmap rating ~10
Compared to Standard-Unices, OpenVMS might offer superior security, mostly because of the privilege model it utilizes instead of giving all-powerful root privileges to many user space applications.
On the other hand, we've got OSs which have much more sophisticated security than OpenVMS.
First, there is IBM's AS/400, which has got a privilege model quite similar in extent to the one used in OpenVMS, but additionally it has object-based design, and therefore object-based security (type enforcement and such...). However, it lacks Mandatory Access Control, TCB, Trusted Path and some other things mostly required by military and/or government environments, and therefore it only achieves a C2 security rating.
And then there are a couple of really secure Trusted Unices/Unix-style OSs, like Trusted Solaris, the Pitbull Addon for Solaris and AIX, Trusted IRIX, or XTS/400.
Just talking about fine-grained privilege controls: Argus' Pitbull has got around 100 privileges, how many privileges are there on an OpenVMS box?
No OS has ever received an A1 security branding. And the only OS which has ever received a B3 security branding, is actually a Trusted Unix Environment, something like a Unix clone with some proprietary security mechanisms built into the kernel (OpenVMS was B1 or maybe B2, iirc).
---
Regarding secure TCP/IP initial sequence number generation, it does not take a Trusted OS to just generate secure sequence numbers.
About two months ago, I compared initial sequence number generation on the following OSs using nmap:
* Windows 95
* Windows ME
* Linux 2.2.x
* Windows 2000 (plain)
* Windows 2000 (with Norton Internet security installed)
* OS/2 Warp Server Advanced 4.0 (default install)
* Sun Solaris 7 x86 (with tcp_strong_iss set to 2)
The results where pretty interesting and also a bit surprising:
Windows 95 was worst (ok, that's not surprising
Then came OS/2, which was not much better, nmap rating ~ 1000
(BTW: does anyone have nmap results from OS/390 or OS/400?)
Even Windows ME was a bit better than OS/2, but still far away from being secure, nmap rating ~ 8000
There was little difference between Win2k with Norton's Firewall (~12000) and Win2k without the Firewall (~15000)
Linux' results were quite good, nmap rating approximately some hundred-thousands or millions
Solaris with tcp_strong_iss set to 2 seemed to offer really strong sequence number generation, so nmap just printed a lot of 9s
---
Additional information:
Here is nmap.
Here is Argus Systems (EAL4 security for Solaris/AIX)
Here is IBM's AS/400
Here is Getronics (B3 secure Unix Environment running Unix and Linux applications)
And finally, here is OpenVMS
We always call time the 4th dimension, so this may be the reason for many of us to believe, that we can simply move something around on the "time line" - just like moving your mouse around on your desk, changing it's x/y/z coordinates.
But time is somehow different, it's more like a result of everything that happens.
Traveling through time on one specific place (not everywhere) would just be like one object in 3-dimensional space which has got 2 x-coordinates, but only 1 y- and 1 z-coordinate.
Doesn't look like we will ever be able to travel through time. We are just constructing too complex solutions around very simple facts, and everything looks right, when it actually isn't, because we do not have enough knowledge to prove our theories. It's always just one theory built on (or proven by) another theory...
This is not true.
An unsecure application running on a Mac makes the Mac even more vulnerable than most other Operating Systems, because under Mac OS every application has full access to all system resources (Mac OS does not have multiuser security).
Instead, if you run a webserver, which is secure to run on a Mac, on Linux or something else (whatever you want), and that webserver does not have security bugs, then any other operating system is even more secure than your Mac, because other operating systems have multiuser security, additionally to the secure webserver.
Mac OS is not a secure OS - maybe you are running a secure webserver on top of the unsecure Mac OS, but then you are talking about the wrong thing, because the webserver does not have anything to do with OS security.
There are *much* more secure operating systems than Mac OS. Most of them would have been able to stop an attacker, who just exploiting a third-party Addon application, because these OSes do not depend on application level security.
Take a look about XTS-400 from Getronics, Pitbull from Argus Systems, Trusted Solaris from Sun or OS/400 from IBM to understand, how real security works (EVEN IF your application gets hacked).
Mac OS is not suitable as a server OS, because it does neither have protected memory nor preemptive multitasking.
Mac OS X might be suitable as a server, but I think it is mainly meant to be a workstation OS.
regards,
octogen
And, by the way, SecureOS from Secure Computing has NEVER been hacked, Argus Pitbull on AIX and on Solaris/SPARC have NEVER been hacked (and only once on Solaris/Intel, Sun's fault, not Argus'), Getronics XTS-400 has NEVER been hacked - although those OSes where running a lot of *insecure* third-party addons.
So please, don't pretend that Mac OS is secure, if you can't prove it.
At least an authorizations/privilege security model instead of the anyone/root distinction is absolutely necessary.
The problem is, that many daemons (like Sendmail and such) override *all* security - of course, this is absolutely unnecessary.
For example, on Argus enhanced systems you run Sendmail with the pv_asn_port privilege instead of root privileges.
If someone manages to hack Sendmail, then the attacker can do nothing else than just open port 25, while on other OSs (even OpenBSD) the attacker gains root privileges.
Sendmail does not need root privileges to run, so why should we give Sendmail root privileges?
One key to more security is the 'principle of least privilege'. Modern Unix Operating Systems like Trusted Solaris show, that it is possible to implement fine-grained privilege control in Unix kernels.
Just securing a few dozens of applications (that's what the OpenBSD project calls OS security?) is not enough.
What if I need to run some other application?
An Operating System should be able to protect data even in the case, that an application gets hacked.
Our real problem is 'root' - it should never be used for any kind of server application (daemon), but only for system administration by an authorized user. There should not be any permanent processes running as root.
LIDS, the grsec patch, NSA's sample implementation of MAC and such things are steps into the right direction.
The worst problem regarding security is probably the fact, that today's mainstream processors mix up code, data and adresses in memory without being able to distinguish between these categories.
You can put anything (even some characters of input from the keyboard) into memory and let the computer use it as a memory address - and this is really a very, very bad architecture.
If an attacker could only modify data by exploiting buffer overflows instead of being able to put additional code on your machine and to execute it, his or her possibilities would be much more limited.
Most secure operating systems can't prevent a security breech within an application, but are still able to prevent access to the OS itself, to other applications or to sensitive data. This is done by strictly following the 'principle of least privilege', which mainly means that you do not run any process with all-powerful root privileges.
(Take a look at Argus' homepage for more information about secure Unix kernels with authorizations/privileges instead of 'root')
IBM invented a technology which would be suitable for protecting the system from unintentionally modified addresses, almost 20 years ago (in the System/38).
We definately need better processors and better operating systems.
A short summary of methods to prevent from buffer overflow exploitation:
* If a process CALLs a subroutine, the return addresses shall become pushed onto the stack and marked as a 'valid address' in some kind of shadow memory (if you have 64bit long addresses, you need 128MB additional memory as the shadow RAM for each 1024MB RAM).
* If some piece of data is MOVed to memory, then the memory region shall become marked as 'non-valid address' in shadow memory.
* If a processor tries to fetch an address from a memory region which is not marked as 'valid address' then the processor shall raise an exception (interrupt) to inform the operating system about the invalid pointer.
* Shadow memory shall only be accessible from the highest privilege level (that is, from kernel mode)
* User mode processes shall not be able to use OS APIs in order to mark modified addresses as 'valid address' unless the user process has the privilege to use the API.
* There should be a privilege which causes the OS to ignore invalid pointers and resume execution of a user process, in order to ensure that even very old programs (which use pointer manipulation without correct casting, etc.) can be used.
Unfortunately, there is almost no information on the net about hardware pointer protection, so you will possibly need to look into Frank Soltis' book "Inside the AS/400" to get very detailed information.
Inside the AS/400, Frank Soltis
The question is not whether *BSDs are dying, but rather whether S/390s are dying.
Unix machines have had more processing power than S/390s for years now, but they did commonly not support block-mode terminals (like S/390's 3270), and therefore it was difficult to implement host-/terminal-based applications on unix-systems without causing too much network traffic.
AS/400's (aka iSeries 400) have got 5250-terminals, which are quite the same as the 3270's, but a few years ago AS/400's did not have as much processing power and/or disk capacity as mainframes. Recent AS/400's are mainly based on pSeries-like hardware, with the same powerful POWER4 processors, lots of cache memory and lots of main storage (RAM).
Since the biggest AS/400s are now more powerful than the biggest z/900 but also are more mainframe-like than the pSeries, it could be possible, that IBM is going to replace the S/390's with the more modern AS/400's.
There is a derivate called "TSSH" (Trusted SSH) which comes with Argus-enhanced Trusted Operating Systems.
Trusted SSH is aware of TCSEC B1 security mechanisms (like Mandatory Access Control), Argus' privilege/authorizations concepts and ASN (Advanced Secure Networking).
You can find a short TSSH FAQ (mostly about its advantages over other commonly used SSH servers) here.
A dual head laptop doesn't seem to make much sense.. does anyone intensively use his or her laptop for CAD/CAM?
;-)
Personally, I would rather prefer having dual CPUs instead of dual heads
Mozilla got a beautiful new GUI, skins, a few more functions, useless things like annoying "do you want to save this password?" messages which can't be turned off and such...
The final result is, that it is still very unstable (better than Netscape 4.7, of course) and relatively unreliable (often destroys its configuration files).
Why did Mozilla's developers spend all their time implementing useless things like skins instead of fixing the REAL problems? I think they could have done a much better job.
Another problem with Mozilla is, that it is extremly slow - especially in 8bit color mode (it renders everything with Steinberg dithering or something like that). Display complex websites can produce as much as 10 seconds full load on an SMP machine until the page gets displayed - while Netscape 4.7 displays the page instantly.
However, I will not use Internet Explorer instead - there are a lot of reasons why I do not like IE, including that it's rather insecure and that I do not like its chaotic User Interface.
Opera seems to be quite good, as long as websites are not too comlex (and I don't like these complex flash-javascript-dhtml pages, either). Reading/posting articles in Slashdot works fine.
Why can't Mozilla simply be faster and more stable?
If people can't get music from audiogalaxy, they will probably rather try to get an illegal copy of the whole album - in even better quality than the mp3 files on AG.
If then they can't copy the CD, they will hardly buy it just because they can't copy it.
Doesn't look like the RIAA is solving any problems!?
If they wanted a cluster, they would rather use a cluster of 32-way POWER4 machines (p690). These big irons scale much better than SMP Athlons and have faster RAMs and Bus systems. Finally, they're much more reliable than PC hardware.
If you have to run applications, where you can not make much use of vectorized instructions, then these systems are not faster than any other computer is, too.
There are two american companies which are developing very impressive technologies:
- IBM tries to build hypercomputers (quantum computers), and research results look pretty promising. - a few images
- They are going to build a One-Petaflop Supercomputer until 2005 utilizing 1,048,576 Processors (32 Cores per Chip, 64 CPUs per Board, 8 Boards per Frame, in 64 Frames) - Blue Gene Project
- They are developing CPU Cores, where all execution units are connected asynchronously - that makes it easy to reach an extremly high clock frequency.
Speed per processor doesn't matter - just think about Intel SMP systems compared to RISC SMPs. Scalability is the one thing that matters in supercomputer technology.
Drop me a mail, and I will give you a prove, that Mac OS 9 is at least as vulnerable as any other platform is, too.
I think, you should distinguish between Operating System Security and Secure Applications on top of an insecure OS.
Mac OS 9 does not have any security.
It's only the webserver which was secure. Use the same webserver on Linux, and Linux is as secure as your Mac.
This level of security can be reachen on ANY platform, including DOS and even Windows 95.
Just disable everything which has something to do with networking, and then install some secure server application.
I'd like to see a Mac OS 9 driven computer that can prevent hackers from destroying data DESPITE the fact that it is running insecure software - THIS would be real OS security.
NSA SELinux is (currently) not meant to be a secure Linux distribution. It's rather something like a "Demo"-Implementation of MAC in the Linux-Kernel.
Quotes: NSA SE-Linux FAQ
13.Is it secure?
[...] Put another way, "secure system" means safe enough to protect some real world information from some real world adversary that the information owner and/or user care about. Security-enhanced Linux is only a research prototype that is intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely to meet any interesting definition of secure system. [...]
16.Did you try to fix any vulnerabilities?
No, we did not look for or find any vulnerabilities in the course of our work. We only changed enough to add our new mechanisms.
You can find the full SE-Linux FAQ here
Would be interesting to see Gary Kasparov play against an off-the-shelf SMP server...
I am almost sure that you do not need a supercomputer to beat human chess players today - something like a p690 or a Fire 15k should have enough cpu power to win most chess games.
Actually, Windows' privilege model is quite ineffective. Many privileges control the LAN-Manager, not the OS Kernel itself (eg. "Create permanently shared objects")
There are privileges like "Control Auditing" - but there is nothing like "allow this process to only ADD audit records to audit files" or "allow this process to only READ audit files".
There is also nothing like "Allow restricted IOCTL calls", "Allow mount/umount".
Windows grants all privileges to users, not to the binaries in the file system. A process can not spawn a more privileged subprocess, because Windows does neither support setuid/setgid, nor does it suppport privilege sets for programs in Windows' file system. All these facts make the Windows privilege concept rather ineffective.
There are _much_ better concepts than the ones found in Windows - maybe take a look at IBM's OS/400, or at Argus Systems' Pitbull Foundation, which implements an even stronger Privileges/Authorizations concept.
On an Argus box, you could, for example, add the PV_FS_MOUNT privilege to the authorized privilege set of some new mount tool binary on your harddisk, and then add the MOUNT authorization to the privileged authorization set of the same binary.
(Maybe set FSF_EPS if the program does not know how to handle privileges)
When a user executes the binary, the operating system would only put the PV_FS_MOUNT privilege into the effective privilege set of the spawned process, if the executing user has the MOUNT authorization (and if the PV_FS_MOUNT privilege is in the limiting privilege set of the process, which execs the binary - commonly the user's shell).
A user without MOUNT authorization could now display a list of all mounted file systems, but he/she could not mount or unmount Filesystems.
Even a user WITH MOUNT authorization could not mount/unmount file systems, if his/her limiting privilege set has been downgraded and for this reason does not contain the PV_FS_MOUNT privilege any longer.
---
YES, we NEED more powerful privilege concepts in Linux (and in ALL other Standard UNIX systems as well), to protect the OS from privileged daemons which get hacked for some reason.
(And this is also the reason why OpenBSD ist NOT really a secure OS - it highly depends on the fact, that only bug-free daemons have root privileges. A really secure OS would not grant any daemon something which is as powerful as root privileges just to open a privileged port or to use some funny special system calls)
Currently, only Trusted Unices offer strong security - however, most users do not need labeled information security (as defined by TCSEC B1), which is rather difficult to administer.
There should be some "light" version of a Trusted Unix OS without Mandatory Access Control (and maybe with a more simple set of privilege) for normal users.
regards,
octogen