The most important thing about a Video Drivers is, that you are able to kill it when it crashes.
Video drivers tend to be buggy (or maybe even the hardware tends to be buggy), and sometimes graphics output freezes.
Virtually NO video card has a reliable RESET-instruction - so when your graphics driver freezes, you can't see anything on the console (or at least not anything you can actually read) - not even if you switch to a text mode shell.
What you have to do is: - log in remotely (e.g., ssh) - kill the X Server - restart the X Server to reinitialize graphics mode - cleanly shut down the X Server to reinitialize text mode - start X Server again
Some graphics cards are even worse, you won't see anything once they've crashed, unless you cold-reboot (power off, power on) your machine.
What I want to say, is: Most graphics cards are a damn stupid pile of crap, and therefore you must at least be able to kill/upgrade/modify their software/drivers without interrupting system operation.
On Unix you can install another graphics card on-the-fly without rebooting - and you can even kill -9 your video drivers if it's neccessary.
I'm running Solaris 7 on a Tyan Dual Pentium III-S, and it works just fine.
I don't think that the Tyan system board is the problem - what about your computer's scsi/graphics/network devices?
Another important thing to mention:
DON'T USE INTEL NETWORK ADAPTERS when running Solaris! All Intel network cards have had a design error for at least 6 years, and Intel still didn't fix that (Windows drivers and the Linux kernel module circumvent the problem, which is called "Receiver lockup bug" by the Linux developer community). The Solaris driver does not fix this (hardware-caused) problem, for this reason the network card may "lock up" sometimes - a cold restart is required to get the network device back online (you really need to pull the plug for at least 20 seconds).
On Intel processors, read- and execute-permission for a memory page is only one flag. For this reason, if you make the stack nonexec on Intel machines, the cpu will have to do a lot of context-switching, because all the protection faults that occur when an application tries to read from a non-exec page need to be handled by the OS kernel.
On SPARC, Alpha or POWER CPUs there is one flag for the read-permission and another one for the execute-permission.
To prevent exploitation of buffer overflows, I believe that we simply need much better hardware.
For example, IBM's AS/400 has Hardware pointer protection. It is absolutely impossible to fake certain types of pointers on the AS/400, because the CPU will recognize when a pointer has been overwritten due to a buffer overflow.
That's how REAL bufferoverflow-protection works. If you just make dataregions nonexecutable, you can still parameterize some kind of library function (how about execve()?) and make the vulnerable program jump into the codesegment to execute the library function with the parameters specified by the attacker.
AS/400s simply 'abuse' one bit in the ECC code as a flag for marking valid pointers.
For every 64 bits in RAM there should be 1 flag bit, which tells the CPU whether the data in memory is a valid pointer or not.
An instruction like LEA (Load effective address) should then implicitly set the flag, and instructions like MOV (Move Data, actually a copy instruction) should always clear the flag.
If a RET (return from subroutine) instruction tries to load an unflagged (=invalid) pointer, the CPU should trap to the OS kernel.
For legacy application, that are too damn stupid to use pointers in a correct way, a privilege could be added to the OS kernel to allow an application to use even invalid pointers.
Furthermore, read- and execute-permission should be separate flags and all stack- and heap-pages should be nonexec by default.
S/390s can scale to 640 processors in a Parallel Sysplex Configuration; however, a parallel sysplex is a multiple-node configuration with multiple operating system images, not an SMP- or NUMA-configuraion with a single OS image.
Afair, the largest S/390 Configuration with a single OS image is 20 CPUs.
Currently, IBM's most powerful Configuration with a single OS image is a 32-processor pSeries 690 (aka RS/6000) Server.
OS/2 SMP has always supported up to 1024 processors
No.
The current release, OS/2 Warp Server 4.5 for e-business, supports up to 64 processors.
Earlier versions had support for 4 or 8 processors.
I remember going to Comdex in 1994 seeing OS/2 2.1 SMP running on 128 processors.
This might have been a multinode-cluster of smaller SMP nodes. OS/2 runs on x86 hardware, and afaik the largest x86-SMP is a 32-processor Unisys ES7000.
IBM's largest SMP configuration, even on their own POWER platform, is 32 processors.
Bigger toys (like ASCI White and such..) are multi-node configurations, but those thingies run AIX, not OS/2.
No, only suid binaries. You don't hack into something which runs in the context of your own account (your own level of access).
Software that uses suid bit set will still be susceptible to leaving control to the "root" user after it crashes
That's the difference between a secure configuration of common OSs like Linux, Free/Net/OpenBSD,... and really secure OSs like VMS or Trusted Solaris (yes, Unix can be a really secure OS).
Secure OSs don't run things as root, they assign privileges to certain users and/or binaries instead. For example, you don't want to allow Apache to override the Discretionary Access Control when it actually only needs 'root' to open port 80.
On Trusted Solaris you just do 'setfpriv -m -a -f net_privaddr/usr/local/apache/bin/httpd' and noone would ever get something like root by hacking into your apache webserver. That's how the 'principle of least privilege' works.
There is mainly one thing wich keeps your system secure: Access restrictions (users must not load kernel modules, mount disks, access files which they're not allowed to access,...). But access restrictions can't protect your system from users/processes who are privileged to override these restrictions, and that's why you need fine grained privilege controls to build really secure OSs.
Linux isn't the only Unix-style OS on this planet.
Go to a Trusted Solaris box and type: man setfattrflag man setfpriv man setlabel man priv_desc
THAT is security. Once you understand Trusted Solaris, you'd rather cry than laugh about Windows 2000's security model.
There are a lot of dangerous design errors in NT, and the design of the NT kernel is absolutely not superior to modern unices.
Linux isn't a good example for a secure operating system, that's correct - and there are some things which NT can do better than Linux - for example, Access Control. But access control alone doesn't help much, when you can easily gain privileges which allow you to circumvent the access control.
But Linux is a Unix-style OS - and as you probably know, the design of the Unix OS is 'open'. If they can build Trusted Solaris, then they can also build something like 'Trusted Linux' - because the design principles of all Unices are mainly the same.
Today, you can buy a Trusted Solaris box with as much as 106 processors (it scales up fine), 576 GBs of RAM and a few terrabytes of DASD and run all this stuff at the TCSEC B2 level (more exactly, mandatory access control/compartmentalization, trusted computing base, least privilege plus privilege inheritance rules, B3 trusted login path, role based access controls, and so on).
Show me the same configuration with NT, and then we'll talk about superior kernel design and superior security mechanisms once again.
So they are going to sell us an operating system, whose API was originally designed as a graphical user interface for DOS, then ported and somehow upgraded to run in hybrid real/protected mode but still on top of some DOS (called Win32), then patched to be multiuser-capable and ported onto a kernel which was originally meant to be something like VMS w/ an OS/2 API until they hacked a Windows API into it (and renamed it as Windows NT), and finally packaged with a pile of user-space programs which let this crap look like a unix shell?
There is so much missing in NT compared to Unix. No VFS-like filesystem, no symbolic links, no device nodes, no setuid/setgid, no privilege sets in the filesystem,...
Even if you add a really powerful shell environment, it still can't compare itself to modern Unices.
Why don't they throw it all away and build a REAL unix instead of bending some wannabe-unix-stuff round a broken Kernel/API design?
Does a so-called professional server- and/or development-platform really need to be compatible with Windows 95/98/ME/Win32?
Fine, but why do you pay for two processors if you only use one? Of course, you can run OpenBSD on an SMP machine, but if I'd like to run a non-SMP-enabled OS, I would certainly not buy an SMP machine.
True. Microsoft tried to migrate those 23 AS/400s (used for internal mission-critical business) to 1200 NT-Servers in 1999/2000, but this pile of hundreds of NT-servers just couldn't do the job. That's why they are still running their AS/400s.
Computers were already able to do things, that brains couldn't do, 20 years ago - regarding speed and precise memory (that's what I call processing power).
Brains will probably always be able to do things, that computers can't do, not even with EXTREMELY much processing power.
Why? ====
A Brain works in a different way. It's good at fuzzy-logic and at distinguishing important from less important information.
To let a computer's pure logical processing power act like a brain, you have to simulate all that "fuzzy-logic" with complicated mathematics.
Computers can do a lot of things, which not even thousands of brains could do correctly, or at least in an acceptable period of time. Weather/climate simulations, sound-processing,... There are also a lot of things, which can only be done by thinking, by being creative,...; someone must write programs for computer to make them work, so there is little chance that computers will ever be more 'intelligent' than the one who learned them how to become intelligent.
We do not even know exactly, what 'intelligent' means, from a technical point of view.
Brains are more powerful than computers, and Computers are more powerful than brains.
That's what you get if you compare apples with pears.
The example you showed will not permit unauthorized code access
On my harddisk I have got another example that shows, how an attacker can fool the program into executing a portion of its code, that would normally never be executed, by exploiting a buffer overflow vulnerability.
It is more difficult for an attacker to exploit buffer overflows on VMS than it is on OpenBSD/Intel, but it's not impossible.
VMS' protection from buffer overflow exploits has similar strenghts and weaknesses as Solaris/SPARC's protection mechanisms. On both platforms you can't execute overflowing data, but you still can play around with existing code - and that's really enough to break the security of either an important application (like a webserver, database,...) or even the whole operating system, if the application has too much privileges.
Protection against buffer overflows does not make a difference between Solaris and VMS. Security mechanisms like least-privilege, compartmentalization are the things, that make the difference. And regarding these things, Trusted Solaris is cleary far superior to SE-VMS.
VMS is architected such that overflowing data cannot be executed
The same is true for Solaris/SPARC, if you configure it correctly.
You don't need to execute overflowing data, it can even be enough only to change a function pointer, and the program would run some code which was already there before the overflow occurred.
This code would be executable, because it's simply a part of the running program or of a library used by the running program.
Just changing some piece of data which gets passed to a system call can also be enough to break security.
From a technical point of view, applications on OpenVMS are just as vulnerable to buffer overflow exploits as applications on Solaris/SPARC (with noexec_user_stack set to 1).
On both OSs you can't execute overflowing data.
But on both OSs you can (sometimes) circumvent this sort of protection.
Ok, so you believe, programs are absolutely immune against buffer overflow exploits on OpenVMS?
Then I'll show you a simple example of a buffer overflow exploit on OpenVMS/Alpha.
---
The victim program compares a user-supplied password with a password stored inside a file.
I wasn't able to include the source code, because I always get errors like "Your comment has too few characters per line (currently 24.5)." if I do. Email me, if you'd like to get the complete source code, and I'll send it back to you.
$ cc vmshackme.c;1
strcpy(l_input, input);.^ %CC-I-IMPLICITFUNC, In this statement, the identifier "strcpy" is implicitly declared as a function. at line number 66 in file $DKA100:[USERS.OCTOGEN]VMSHACKME.C;1
if (strncmp(l_input, l_pass, _max_pwd_len) == 0).....^ %CC-I-IMPLICITFUNC, In this statement, the identifier "strncmp" is implicitly declared as a function. at line number 68 in file $DKA100:[USERS.OCTOGEN]VMSHACKME.C;1 $ link vmshackme.obj;1 $ type pass.pwd;1 openvms $ run vmshackme openvms Password correct $ run vmshackme os400 Wrong password, try again. $
-----
The program works, as you can see.
Now I'll type in a bit too much:
$ run vmshackme aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Pass word correct $
-----
What I'm exploiting here is nothing else than a simple example of a buffer overflow.
Even if you can't execute arbitrary code (and I'm quite sure you can do that, too!), you can still damage data structures, data pointers, numeric values like buffer offsets and many other things - so there are a lot of possibilities left for exploiting a buffer overflow vulnerability. AS/400s have hardware protection for system pointers, so they are even more secure than OpenVMS. But even on AS/400s you can still damage space pointers, and I'm quite sure, this example program would even work on an AS/400. It might not be possible to execute arbitrary code on an AS/400, but you can still damage many things by exploiting buffer overflows.
i c, my fault, should've been: Everything from B1 up to A1 (A1 never ever reached by any OS).
Boeing MLS LAN and Gemini Trusted Network Processor are Network Components, not Operating Systems. Honeywell SCOMP is an integrated computing platform, running Getronics XTS/300.
XTS/300 without SCOMP is only evaluated at the B3 level.
And what's up with that "the most secure os" sarcasm? OpenBSD *is* secure.
This definition depends on what you call "secure".
Theo calls an OS with a very limited, trusted set of applications "secure" - however, running secure applications with root privileges has nothing to do with OS level security. That's application level security.
I'd call an OS secure, if you can only hack it by exploiting a bug inside the OS kernel. That means, there is no way of gaining 'root' privileges or something like that by hacking into some highly privileged daemon, provided that the system is configured properly.
To achieve this level of security, it is neccessary to have fine grained privilege and compartmentalization controls instead of the superuser/world distinction built into the OS kernel - and that's still missing in OpenBSD.
What means "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. [...]" - SE Linux FAQ, NSA
-----
There are mainly two types of secure Operating Systems. a) Everything up to the C2 level of security b) Everything from B1 up to A1 (never ever reached by any OS)
The difference is information labeling. You only get a B1 security certificate, if your OS has mandatory access controls. It must be able to automatically prevent users from mixing secret data with public data. This is often called a "Trusted OS".
Most people don't need information labeling/mandatory access control, because all their data has the same level of sensivity.
TCSEC C2 does not say much about how the OS has to handle privileges, so a C2-level OS can still be very insecure, but it can also be very secure - almost impenetrable - and it still can't ever become certified at B1 or above, because it simply can't handle multiple levels of sensivity.
-----
Let's look at NON-Trusted-OSs first, because most people don't need a Trusted OS:
OpenBSD lacks an uninterceptable audit trail and access control lists as required by TCSEC C2. It distinguishes between world and root privileges.
VMS has an audit trail, access control lists, and a privilege model.
AS/400s have an audit trail, access control lists, a privilege model, an object-based security model with type enforcement and hardware-supported pointer-in-memory-protection because of the single level storage address space, but that does not matter much (think about it as something which is similar to protect-mode on an x86, but based on objects and pointer to objects instead of segments and segment descriptors).
VMS is clearly superior to OpenBSD, mainly because of the privilege model. If a process does not have many privileges, then an attacker can't gain many privileges by hacking it. Simple, isn't it?
An AS/400 is (VMS users listen carefully) clearly superior to both, OpenBSD and VMS. It has a superset of the security features of VMS, and additionally it has object-based protection. Therefore, you can't write to a program object, and you can't execute a data file or things like that.
Now let's look at Trusted OSs:
SE-VMS has an audit trail, access control lists, a privilege model, information labeling and compartment mode.
Solaris with Argus Pitbull has an audit trail, access control lists, fine grained privilege controls plus inheritance rules (proxy privilege sets and so on), a trusted computing base, information labeling and compartment mode (mandatory access controls).
Both are clearly superior to the non-trusted OSs mentioned above, because applications can be totally separated from each other by putting them in separate compartments. If someone hacks into an application in compartment A, then he/she still can't access an application in compartment B, so he/she is locked down into a jail.
Solaris with Pitbull is clearly superior to VMS, because of the much more sophisticated privilege model. It's more fine-grained and it has inheritance controls, so certain applications will only gain their privileges if they can inherit those privileges from another process. By default, executing another application always drops all privileges.
-----
What I'd like to say is.. 2 things:
1. What about "OpenBSD is the world's most secure OS"? It has a pretty good verified kernel, but it's security mechanisms are simply not powerful enough. A bug-free kernel does not help alot, when you have to run things as root, because the kernel does not have appropriate security mechanisms like privilege controls or compartment mode...
2. What about "Unix can't be secure"? I get really bored by VMS users comparing Standard-Linux with VMS; maybe compare the most secure setup of either Operating System and then let's talk about security again. HERE is TCSEC B3 certified Unix (Linux-compatible, too).
Security Patches have been available for free at sun's homepage, I hope this is still true.
However, I'd be even more interested in a Trusted Solaris 9 Release for x86. TS 8 was available for x86, at a price of about $ 2500,- (this is for a 2-way machine, there is no single-cpu license for TS; thanx god i've wasted my money for an smp machine, so i don't have to waste money for an 'oversized' license;-)
IMHO, Trusted Solaris is the ultimate combination of scalability and security on x86 - at least I did not find anything comparable on the x86.. (ok, maybe except Solaris with Pitbull, which is pretty similar to Trusted Solaris anyway...)
I'd recommend having a separate data stacks and address stacks, or some kind of hardware-supported pointer protection (for example, IBM's AS/400s have hardware pointer protection for certain kinds of pointers, therefore you can't fake these pointers by overwriting them with data)
Ok, but in real life we have got bugs in software. Only adding security features without any assurance, that these features can be effectively enforced by the TCB is rather worthless in real life use.
you can restrict the communication of programs such that they can only communicate with a select few.
You can do the same by using Mandatory Access Controls, and this is actually more effective, because MAC protection is not only enforced on objects (data containers), but rather on the information contained inside objects, depending on the sensivity of the information.
We always want to protect some piece of information. By using capabilities you just turn access to an object on or off. By using MAC you define a security policy, which automatically manages access to sensitive information, no matter in what kind of object it is contained or where it comes from.
Yes, capabilities are protected by the small trusted kernel-level code base.
As on all other operating systems. There are unix operating systems that are virtually impenetrable (however, as we know, nobody can guarantee a 100% secure solution). If you don't want to let programs access data which does not belong to the program - simply lock it down into its own compartment and all the problems are gone.
There are only few way which allow for hacking a high-assurance OS: * Administration mistakes (No difference between capability based and access list based systems) * Kernel bugs (No difference here...) * Exploitation of highly privileged processes (Which may or may not exist on both types of system, depending on how the system is used)
I'm still not convinced that capabilities are really better than what we already have. EROS lacks information labeling, and it seems to be even more difficult to administer. It's just not flexible enough. To me it looks more like a data sharing network between multiple LPARs on a Mainframe or something like that, and that is absolutely not a very useful solution for handling sensitive data.
There are still a lot of problems with capabilities.
* Simple security paradigm with a single simple-logic security test per request. What if you delete an object? You'd have to revoke capabilities on all processes, or otherwise these processes could gain access to re-allocated space - this would compromise the object-reuse-protection mechanismn.
The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc). But you would have to define different capabilities for the same program used by different users, because you don't want user A to read user B's files with the mail program that both users share. Still not very simple.
No global namespace Another thing which makes it pretty complicated. How do you manage your data? You could only manage mail files with your mail program, sound files with your mp3 player, and so on..
The catch is that user A has no way to know what other programs are running on behalf of user B. All of these programs will gain access to C when userB is added to the access list for C. There is no way to grant object access to a single program B without potentially granting access to other programs as well.
In a capability system, the transfer is restricted to program B, because the capability is transfered only to program B. The default situation is that other programs do not gain access to the object.(http://www.eros-os.org/faq/basics.html#wha tis-capability)
As soon as you break into a program which has a certain capability, you can transfer this capability to another program.
The result is exactly the same: You're potentially granting access to all other applications. Still not secure.
The most secure solution for very restricted data sharing is still compartment mode and information labeling. Modern unix environments use a combination of access lists (for access to objects), capabilities (for process privileges) and capability inheritance controls. One of these systems is the only Operating System which is evaluated at the TCSEC B3 level by NSA (for those who don't know it: that means ZERO DESIGN FLAWS)
---
There are a lot of other problems with capability-based systems, especially when you want to share data between processes (and that's probably why you're using ONE computer for two programs and not TWO computers for two programs. Commercial applications need to share data).
IBM's S/38 (the predecessor of the AS/400) had a capability-based access control, which needed only one initial security check, and then used the capability to allow access to a certain object. Object reuse protection was available, because neither S/38's nor AS/400's ever reuse a virtual memory address.
On the AS/400 the capability flag in object pointers can't be used by user space applications any more, because of the problems related with revoking access to objects after a process has been granted access to an object by giving it a capability. Only the SLIC kernel allows itself to hold capabilities.
Another very important thing (perhaps the most important thing at all) is, that a capability is nothing else than a piece of data which can be used by a program - for example, a pointer with a certain bit set or cleared, indication valid authority (security checks performed) or invalid authority (security checks not performed).
Therefore you also need to protect these pointers from modification (IBM's AS/400 has pointer protection for object pointers built into the hardware, but don't confuse this with space pointers - this has only little to do with protection from buffer overflows and such, it's more like protected mode on other platforms, because AS/400s have a virtual single level store and for this reason you need some kind of protected pointer; complicated, as u can see).
So how do you protect a program which has some capability from modifying some pointer or other data structure which has something to do with the capability? You still need something like a system call everytime you use a capability, because you need to go into kernel mode to be able to work with capabilities that are protected from modification by user space processes.
---
I'd recommend you read 'Fortress Rochester'. This book was written by Frank Soltis, the system architect of the S/38 and the AS/400; in his book he explains some of the problems involved with capability-based access control, and why capabilites have been moved out of (even hardware protected!) system pointers on the AS/400.
There are different kinds of philosophy regarding privilege management.
Granting privileges to binaries, authorizations to users Trusted Unices commonly grant privileges to binaries, but only let the process use the privilege, when the user who executes the binary has got a certain authorization.
For example, there is one Authorized Privilege Set (APS) and one Privileged Authorization Set (PAS). You put the PV_FS_MOUNT privilege into the APS, and you put the MOUNT authorization into the PAS. If the user who executes the binary has a MOUNT authorization, then the process gains the PV_FS_MOUNT privilege, and the user can use the program to mount or unmount filesystems. If the user who executes the binary does not have a MOUNT authorization, then the process does not gain the PV_FS_MOUNT privilege, and therefore the user can't mount or unmount filesystems. (This explaination is a bit simplified, because you would also have to look at the limiting privilege set or limiting authorization set, but that does not matter here) This is how Pitbull.comPack works, which is an EAL4 (exceeding B1) kernel security addon for Solaris and AIX.
Granting privileges to users, running processes with adopted authority The other way is to grant privileges to users, and then to let a binary run with the privileges of a specific user added to the privileges of the current user (Adopted Authority).
For example you put the ALLOBJ privilege into the privilege set for user 'John', and you give some binary an adopted authority from user 'John'. User 'Mark', who does not have the ALLOBJ privilege, executes the binary, and the process gains (adopts) all privileges from user 'John', so user 'Mark' can run the program with the ALLOBJ privilege. This is how the SLIC part of OS/400 works (SLIC is the operating system kernel of OS/400, running on IBM AS/400 computers). [Tell me if I got something wrong here, I'm not an OS/400 expert]
Granting privileges to users makes administration easier and it's powerful enough for almost any scenario; granting privileges to binaries makes it a bit more difficult but also more powerful, and i guess that's why it is the preferred method used by Trusted Operating Systems.
Slashdot Mirror
The most important thing about a Video Drivers is, that you are able to kill it when it crashes.
Video drivers tend to be buggy (or maybe even the hardware tends to be buggy), and sometimes graphics output freezes.
Virtually NO video card has a reliable RESET-instruction - so when your graphics driver freezes, you can't see anything on the console (or at least not anything you can actually read) - not even if you switch to a text mode shell.
What you have to do is:
- log in remotely (e.g., ssh)
- kill the X Server
- restart the X Server to reinitialize graphics mode
- cleanly shut down the X Server to reinitialize text mode
- start X Server again
Some graphics cards are even worse, you won't see anything once they've crashed, unless you cold-reboot (power off, power on) your machine.
What I want to say, is: Most graphics cards are a damn stupid pile of crap, and therefore you must at least be able to kill/upgrade/modify their software/drivers without interrupting system operation.
On Unix you can install another graphics card on-the-fly without rebooting - and you can even kill -9 your video drivers if it's neccessary.
I'm running Solaris 7 on a Tyan Dual Pentium III-S, and it works just fine.
I don't think that the Tyan system board is the problem - what about your computer's scsi/graphics/network devices?
Another important thing to mention:
DON'T USE INTEL NETWORK ADAPTERS when running Solaris! All Intel network cards have had a design error for at least 6 years, and Intel still didn't fix that (Windows drivers and the Linux kernel module circumvent the problem, which is called "Receiver lockup bug" by the Linux developer community). The Solaris driver does not fix this (hardware-caused) problem, for this reason the network card may "lock up" sometimes - a cold restart is required to get the network device back online (you really need to pull the plug for at least 20 seconds).
On Intel processors, read- and execute-permission for a memory page is only one flag. For this reason, if you make the stack nonexec on Intel machines, the cpu will have to do a lot of context-switching, because all the protection faults that occur when an application tries to read from a non-exec page need to be handled by the OS kernel.
On SPARC, Alpha or POWER CPUs there is one flag for the read-permission and another one for the execute-permission.
To prevent exploitation of buffer overflows, I believe that we simply need much better hardware.
For example, IBM's AS/400 has Hardware pointer protection. It is absolutely impossible to fake certain types of pointers on the AS/400, because the CPU will recognize when a pointer has been overwritten due to a buffer overflow.
That's how REAL bufferoverflow-protection works. If you just make dataregions nonexecutable, you can still parameterize some kind of library function (how about execve()?) and make the vulnerable program jump into the codesegment to execute the library function with the parameters specified by the attacker.
AS/400s simply 'abuse' one bit in the ECC code as a flag for marking valid pointers.
For every 64 bits in RAM there should be 1 flag bit, which tells the CPU whether the data in memory is a valid pointer or not.
An instruction like LEA (Load effective address) should then implicitly set the flag, and instructions like MOV (Move Data, actually a copy instruction) should always clear the flag.
If a RET (return from subroutine) instruction tries to load an unflagged (=invalid) pointer, the CPU should trap to the OS kernel.
For legacy application, that are too damn stupid to use pointers in a correct way, a privilege could be added to the OS kernel to allow an application to use even invalid pointers.
Furthermore, read- and execute-permission should be separate flags and all stack- and heap-pages should be nonexec by default.
S/390s can scale to 640 processors in a Parallel Sysplex Configuration; however, a parallel sysplex is a multiple-node configuration with multiple operating system images, not an SMP- or NUMA-configuraion with a single OS image.
Afair, the largest S/390 Configuration with a single OS image is 20 CPUs.
Currently, IBM's most powerful Configuration with a single OS image is a 32-processor pSeries 690 (aka RS/6000) Server.
OS/2 SMP has always supported up to 1024 processors
No.
The current release, OS/2 Warp Server 4.5 for e-business, supports up to 64 processors.
Earlier versions had support for 4 or 8 processors.
I remember going to Comdex in 1994 seeing OS/2 2.1 SMP running on 128 processors.
This might have been a multinode-cluster of smaller SMP nodes. OS/2 runs on x86 hardware, and afaik the largest x86-SMP is a 32-processor Unisys ES7000.
IBM's largest SMP configuration, even on their own POWER platform, is 32 processors.
Bigger toys (like ASCI White and such..) are multi-node configurations, but those thingies run AIX, not OS/2.
The userland software in question is: all of it.
/usr/local/apache/bin/httpd' and noone would ever get something like root by hacking into your apache webserver.
...). But access restrictions can't protect your system from users/processes who are privileged to override these restrictions, and that's why you need fine grained privilege controls to build really secure OSs.
No, only suid binaries. You don't hack into something which runs in the context of your own account (your own level of access).
Software that uses suid bit set will still be susceptible to leaving control to the "root" user after it crashes
That's the difference between a secure configuration of common OSs like Linux, Free/Net/OpenBSD,... and really secure OSs like VMS or Trusted Solaris (yes, Unix can be a really secure OS).
Secure OSs don't run things as root, they assign privileges to certain users and/or binaries instead. For example, you don't want to allow Apache to override the Discretionary Access Control when it actually only needs 'root' to open port 80.
On Trusted Solaris you just do 'setfpriv -m -a -f net_privaddr
That's how the 'principle of least privilege' works.
There is mainly one thing wich keeps your system secure: Access restrictions (users must not load kernel modules, mount disks, access files which they're not allowed to access,
I don't know of one system that advertises itself as "secure" other than OpenBSD.
.comPack, Trusted [Solaris|Irix|DG/UX], AIX B1-EST/X, XTS/400, ...
OpenVMS/SE-VMS, OS/400, HP/UX BLS, Linux w/ Pitbull/LX, Solaris/AIX w/ Pitbull
ok, none of these systems is totally open source, but all of them have pretty good security
It's you who doesn't understand.
Linux isn't the only Unix-style OS on this planet.
Go to a Trusted Solaris box and type:
man setfattrflag
man setfpriv
man setlabel
man priv_desc
THAT is security. Once you understand Trusted Solaris, you'd rather cry than laugh about Windows 2000's security model.
There are a lot of dangerous design errors in NT, and the design of the NT kernel is absolutely not superior to modern unices.
Linux isn't a good example for a secure operating system, that's correct - and there are some things which NT can do better than Linux - for example, Access Control.
But access control alone doesn't help much, when you can easily gain privileges which allow you to circumvent the access control.
But Linux is a Unix-style OS - and as you probably know, the design of the Unix OS is 'open'. If they can build Trusted Solaris, then they can also build something like 'Trusted Linux' - because the design principles of all Unices are mainly the same.
Today, you can buy a Trusted Solaris box with as much as 106 processors (it scales up fine), 576 GBs of RAM and a few terrabytes of DASD and run all this stuff at the TCSEC B2 level (more exactly, mandatory access control/compartmentalization, trusted computing base, least privilege plus privilege inheritance rules, B3 trusted login path, role based access controls, and so on).
Show me the same configuration with NT, and then we'll talk about superior kernel design and superior security mechanisms once again.
So they are going to sell us an operating system, whose API was originally designed as a graphical user interface for DOS, then ported and somehow upgraded to run in hybrid real/protected mode but still on top of some DOS (called Win32), then patched to be multiuser-capable and ported onto a kernel which was originally meant to be something like VMS w/ an OS/2 API until they hacked a Windows API into it (and renamed it as Windows NT), and finally packaged with a pile of user-space programs which let this crap look like a unix shell?
...
There is so much missing in NT compared to Unix. No VFS-like filesystem, no symbolic links, no device nodes, no setuid/setgid, no privilege sets in the filesystem,
Even if you add a really powerful shell environment, it still can't compare itself to modern Unices.
Why don't they throw it all away and build a REAL unix instead of bending some wannabe-unix-stuff round a broken Kernel/API design?
Does a so-called professional server- and/or development-platform really need to be compatible with Windows 95/98/ME/Win32?
Fine, but why do you pay for two processors if you only use one? Of course, you can run OpenBSD on an SMP machine, but if I'd like to run a non-SMP-enabled OS, I would certainly not buy an SMP machine.
Oh, and they use AS-400s too.
True. Microsoft tried to migrate those 23 AS/400s (used for internal mission-critical business) to 1200 NT-Servers in 1999/2000, but this pile of hundreds of NT-servers just couldn't do the job. That's why they are still running their AS/400s.
Computers were already able to do things, that brains couldn't do, 20 years ago - regarding speed and precise memory (that's what I call processing power).
... ...; someone must write programs for computer to make them work, so there is little chance that computers will ever be more 'intelligent' than the one who learned them how to become intelligent.
Brains will probably always be able to do things, that computers can't do, not even with EXTREMELY much processing power.
Why?
====
A Brain works in a different way. It's good at fuzzy-logic and at distinguishing important from less important information.
To let a computer's pure logical processing power act like a brain, you have to simulate all that "fuzzy-logic" with complicated mathematics.
Computers can do a lot of things, which not even thousands of brains could do correctly, or at least in an acceptable period of time. Weather/climate simulations, sound-processing,
There are also a lot of things, which can only be done by thinking, by being creative,
We do not even know exactly, what 'intelligent' means, from a technical point of view.
Brains are more powerful than computers, and Computers are more powerful than brains.
That's what you get if you compare apples with pears.
Providers should immediatly block all traffic to any server, which is used for spamming.
/dev/null
Webspace-Providers, who host homepages which are promoted via spam email, should delete these homepages.
-----
spammer of month: netm*ils.com
let's mv netm*ils.com
The example you showed will not permit unauthorized code access
On my harddisk I have got another example that shows, how an attacker can fool the program into executing a portion of its code, that would normally never be executed, by exploiting a buffer overflow vulnerability.
It is more difficult for an attacker to exploit buffer overflows on VMS than it is on OpenBSD/Intel, but it's not impossible.
VMS' protection from buffer overflow exploits has similar strenghts and weaknesses as Solaris/SPARC's protection mechanisms.
On both platforms you can't execute overflowing data, but you still can play around with existing code - and that's really enough to break the security of either an important application (like a webserver, database,...) or even the whole operating system, if the application has too much privileges.
Protection against buffer overflows does not make a difference between Solaris and VMS. Security mechanisms like least-privilege, compartmentalization are the things, that make the difference. And regarding these things, Trusted Solaris is cleary far superior to SE-VMS.
VMS is architected such that overflowing data cannot be executed
The same is true for Solaris/SPARC, if you configure it correctly.
You don't need to execute overflowing data, it can even be enough only to change a function pointer, and the program would run some code which was already there before the overflow occurred.
This code would be executable, because it's simply a part of the running program or of a library used by the running program.
Just changing some piece of data which gets passed to a system call can also be enough to break security.
From a technical point of view, applications on OpenVMS are just as vulnerable to buffer overflow exploits as applications on Solaris/SPARC (with noexec_user_stack set to 1).
On both OSs you can't execute overflowing data.
But on both OSs you can (sometimes) circumvent this sort of protection.
(Buffer overflow exploits? No such thing in VMS.)
.^
.....^
s word correct
Ok, so you believe, programs are absolutely immune against buffer overflow exploits on OpenVMS?
Then I'll show you a simple example of a buffer overflow exploit on OpenVMS/Alpha.
---
The victim program compares a user-supplied password with a password stored inside a file.
I wasn't able to include the source code, because I always get errors like "Your comment has too few characters per line (currently 24.5)." if I do.
Email me, if you'd like to get the complete source code, and I'll send it back to you.
$ cc vmshackme.c;1
strcpy(l_input, input);
%CC-I-IMPLICITFUNC, In this statement, the identifier "strcpy" is implicitly declared as a function.
at line number 66 in file $DKA100:[USERS.OCTOGEN]VMSHACKME.C;1
if (strncmp(l_input, l_pass, _max_pwd_len) == 0)
%CC-I-IMPLICITFUNC, In this statement, the identifier "strncmp" is implicitly declared as a function.
at line number 68 in file $DKA100:[USERS.OCTOGEN]VMSHACKME.C;1
$ link vmshackme.obj;1
$ type pass.pwd;1
openvms
$ run vmshackme
openvms
Password correct
$ run vmshackme
os400
Wrong password, try again.
$
-----
The program works, as you can see.
Now I'll type in a bit too much:
$ run vmshackme
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Pas
$
-----
What I'm exploiting here is nothing else than a simple example of a buffer overflow.
Even if you can't execute arbitrary code (and I'm quite sure you can do that, too!), you can still damage data structures, data pointers, numeric values like buffer offsets and many other things - so there are a lot of possibilities left for exploiting a buffer overflow vulnerability.
AS/400s have hardware protection for system pointers, so they are even more secure than OpenVMS. But even on AS/400s you can still damage space pointers, and I'm quite sure, this example program would even work on an AS/400.
It might not be possible to execute arbitrary code on an AS/400, but you can still damage many things by exploiting buffer overflows.
---
regards,
octogen
There are several OS's rated B1 or above.
i c, my fault, should've been:
Everything from B1 up to A1 (A1 never ever reached by any OS).
Boeing MLS LAN and Gemini Trusted Network Processor are Network Components, not Operating Systems. Honeywell SCOMP is an integrated computing platform, running Getronics XTS/300.
XTS/300 without SCOMP is only evaluated at the B3 level.
And what's up with that "the most secure os" sarcasm? OpenBSD *is* secure.
.. 2 things:
This definition depends on what you call "secure".
Theo calls an OS with a very limited, trusted set of applications "secure" - however, running secure applications with root privileges has nothing to do with OS level security. That's application level security.
I'd call an OS secure, if you can only hack it by exploiting a bug inside the OS kernel. That means, there is no way of gaining 'root' privileges or something like that by hacking into some highly privileged daemon, provided that the system is configured properly.
To achieve this level of security, it is neccessary to have fine grained privilege and compartmentalization controls instead of the superuser/world distinction built into the OS kernel - and that's still missing in OpenBSD.
What means "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. [...]"
- SE Linux FAQ, NSA
-----
There are mainly two types of secure Operating Systems.
a) Everything up to the C2 level of security
b) Everything from B1 up to A1 (never ever reached by any OS)
The difference is information labeling.
You only get a B1 security certificate, if your OS has mandatory access controls. It must be able to automatically prevent users from mixing secret data with public data. This is often called a "Trusted OS".
Most people don't need information labeling/mandatory access control, because all their data has the same level of sensivity.
TCSEC C2 does not say much about how the OS has to handle privileges, so a C2-level OS can still be very insecure, but it can also be very secure - almost impenetrable - and it still can't ever become certified at B1 or above, because it simply can't handle multiple levels of sensivity.
-----
Let's look at NON-Trusted-OSs first, because most people don't need a Trusted OS:
OpenBSD lacks an uninterceptable audit trail and access control lists as required by TCSEC C2. It distinguishes between world and root privileges.
VMS has an audit trail, access control lists, and a privilege model.
AS/400s have an audit trail, access control lists, a privilege model, an object-based security model with type enforcement and hardware-supported pointer-in-memory-protection because of the single level storage address space, but that does not matter much (think about it as something which is similar to protect-mode on an x86, but based on objects and pointer to objects instead of segments and segment descriptors).
VMS is clearly superior to OpenBSD, mainly because of the privilege model. If a process does not have many privileges, then an attacker can't gain many privileges by hacking it. Simple, isn't it?
An AS/400 is (VMS users listen carefully) clearly superior to both, OpenBSD and VMS. It has a superset of the security features of VMS, and additionally it has object-based protection. Therefore, you can't write to a program object, and you can't execute a data file or things like that.
Now let's look at Trusted OSs:
SE-VMS has an audit trail, access control lists, a privilege model, information labeling and compartment mode.
Solaris with Argus Pitbull has an audit trail, access control lists, fine grained privilege controls plus inheritance rules (proxy privilege sets and so on), a trusted computing base, information labeling and compartment mode (mandatory access controls).
Both are clearly superior to the non-trusted OSs mentioned above, because applications can be totally separated from each other by putting them in separate compartments.
If someone hacks into an application in compartment A, then he/she still can't access an application in compartment B, so he/she is locked down into a jail.
Solaris with Pitbull is clearly superior to VMS, because of the much more sophisticated privilege model. It's more fine-grained and it has inheritance controls, so certain applications will only gain their privileges if they can inherit those privileges from another process. By default, executing another application always drops all privileges.
-----
What I'd like to say is
1. What about "OpenBSD is the world's most secure OS"? It has a pretty good verified kernel, but it's security mechanisms are simply not powerful enough. A bug-free kernel does not help alot, when you have to run things as root, because the kernel does not have appropriate security mechanisms like privilege controls or compartment mode...
2. What about "Unix can't be secure"? I get really bored by VMS users comparing Standard-Linux with VMS; maybe compare the most secure setup of either Operating System and then let's talk about security again.
HERE is TCSEC B3 certified Unix (Linux-compatible, too).
regards,
octogen
Security Patches have been available for free at sun's homepage, I hope this is still true.
;-)
However, I'd be even more interested in a Trusted Solaris 9 Release for x86. TS 8 was available for x86, at a price of about $ 2500,- (this is for a 2-way machine, there is no single-cpu license for TS; thanx god i've wasted my money for an smp machine, so i don't have to waste money for an 'oversized' license
IMHO, Trusted Solaris is the ultimate combination of scalability and security on x86 - at least I did not find anything comparable on the x86..
(ok, maybe except Solaris with Pitbull, which is pretty similar to Trusted Solaris anyway...)
For the last 30-40 years, the most common programmer error is to put 2769 bytes in where only 1024 fit.
// *BOOM*
That looks like...
void copyit(char *b)
{
char a[1024];
strcpy((char *)&a,b);
}
Simple, but look at bugtraq... programmers still can't do it right..
I'd recommend having a separate data stacks and address stacks, or some kind of hardware-supported pointer protection (for example, IBM's AS/400s have hardware pointer protection for certain kinds of pointers, therefore you can't fake these pointers by overwriting them with data)
By the way - does anyone know, on what kind of Hardware and/or Software these DNS servers are running?
Could a single powerful server (a Sun Fire 15k or something similar) theoretically do the job?
Bugs are not being discussed here
Ok, but in real life we have got bugs in software. Only adding security features without any assurance, that these features can be effectively enforced by the TCB is rather worthless in real life use.
you can restrict the communication of programs such that they can only communicate with a select few.
You can do the same by using Mandatory Access Controls, and this is actually more effective, because MAC protection is not only enforced on objects (data containers), but rather on the information contained inside objects, depending on the sensivity of the information.
We always want to protect some piece of information. By using capabilities you just turn access to an object on or off. By using MAC you define a security policy, which automatically manages access to sensitive information, no matter in what kind of object it is contained or where it comes from.
Yes, capabilities are protected by the small trusted kernel-level code base.
As on all other operating systems. There are unix operating systems that are virtually impenetrable (however, as we know, nobody can guarantee a 100% secure solution).
If you don't want to let programs access data which does not belong to the program - simply lock it down into its own compartment and all the problems are gone.
There are only few way which allow for hacking a high-assurance OS:
* Administration mistakes
(No difference between capability based and access list based systems)
* Kernel bugs
(No difference here...)
* Exploitation of highly privileged processes
(Which may or may not exist on both types of system, depending on how the system is used)
I'm still not convinced that capabilities are really better than what we already have. EROS lacks information labeling, and it seems to be even more difficult to administer. It's just not flexible enough. To me it looks more like a data sharing network between multiple LPARs on a Mainframe or something like that, and that is absolutely not a very useful solution for handling sensitive data.
There are still a lot of problems with capabilities.
..
a tis-capability)
* Simple security paradigm with a single simple-logic security test per request.
What if you delete an object? You'd have to revoke capabilities on all processes, or otherwise these processes could gain access to re-allocated space - this would compromise the object-reuse-protection mechanismn.
The principle of least privelege (Your mp3 player cannot delete your files, your email client cannot listen on any port, etc).
But you would have to define different capabilities for the same program used by different users, because you don't want user A to read user B's files with the mail program that both users share. Still not very simple.
No global namespace
Another thing which makes it pretty complicated. How do you manage your data? You could only manage mail files with your mail program, sound files with your mp3 player, and so on
The catch is that user A has no way to know what other programs are running on behalf of user B. All of these programs will gain access to C when userB is added to the access list for C. There is no way to grant object access to a single program B without potentially granting access to other programs as well.
In a capability system, the transfer is restricted to program B, because the capability is transfered only to program B. The default situation is that other programs do not gain access to the object.(http://www.eros-os.org/faq/basics.html#wh
As soon as you break into a program which has a certain capability, you can transfer this capability to another program.
The result is exactly the same: You're potentially granting access to all other applications. Still not secure.
The most secure solution for very restricted data sharing is still compartment mode and information labeling.
Modern unix environments use a combination of access lists (for access to objects), capabilities (for process privileges) and capability inheritance controls. One of these systems is the only Operating System which is evaluated at the TCSEC B3 level by NSA (for those who don't know it: that means ZERO DESIGN FLAWS)
---
There are a lot of other problems with capability-based systems, especially when you want to share data between processes (and that's probably why you're using ONE computer for two programs and not TWO computers for two programs. Commercial applications need to share data).
IBM's S/38 (the predecessor of the AS/400) had a capability-based access control, which needed only one initial security check, and then used the capability to allow access to a certain object.
Object reuse protection was available, because neither S/38's nor AS/400's ever reuse a virtual memory address.
On the AS/400 the capability flag in object pointers can't be used by user space applications any more, because of the problems related with revoking access to objects after a process has been granted access to an object by giving it a capability. Only the SLIC kernel allows itself to hold capabilities.
Another very important thing (perhaps the most important thing at all) is, that a capability is nothing else than a piece of data which can be used by a program - for example, a pointer with a certain bit set or cleared, indication valid authority (security checks performed) or invalid authority (security checks not performed).
Therefore you also need to protect these pointers from modification (IBM's AS/400 has pointer protection for object pointers built into the hardware, but don't confuse this with space pointers - this has only little to do with protection from buffer overflows and such, it's more like protected mode on other platforms, because AS/400s have a virtual single level store and for this reason you need some kind of protected pointer; complicated, as u can see).
So how do you protect a program which has some capability from modifying some pointer or other data structure which has something to do with the capability? You still need something like a system call everytime you use a capability, because you need to go into kernel mode to be able to work with capabilities that are protected from modification by user space processes.
---
I'd recommend you read 'Fortress Rochester'. This book was written by Frank Soltis, the system architect of the S/38 and the AS/400; in his book he explains some of the problems involved with capability-based access control, and why capabilites have been moved out of (even hardware protected!) system pointers on the AS/400.
It's not about ACLs, it's about privileges.
.comPack works, which is an EAL4 (exceeding B1) kernel security addon for Solaris and AIX.
There are different kinds of philosophy regarding privilege management.
Granting privileges to binaries, authorizations to users
Trusted Unices commonly grant privileges to binaries, but only let the process use the privilege, when the user who executes the binary has got a certain authorization.
For example, there is one Authorized Privilege Set (APS) and one Privileged Authorization Set (PAS). You put the PV_FS_MOUNT privilege into the APS, and you put the MOUNT authorization into the PAS.
If the user who executes the binary has a MOUNT authorization, then the process gains the PV_FS_MOUNT privilege, and the user can use the program to mount or unmount filesystems.
If the user who executes the binary does not have a MOUNT authorization, then the process does not gain the PV_FS_MOUNT privilege, and therefore the user can't mount or unmount filesystems.
(This explaination is a bit simplified, because you would also have to look at the limiting privilege set or limiting authorization set, but that does not matter here)
This is how Pitbull
Granting privileges to users, running processes with adopted authority
The other way is to grant privileges to users, and then to let a binary run with the privileges of a specific user added to the privileges of the current user (Adopted Authority).
For example you put the ALLOBJ privilege into the privilege set for user 'John', and you give some binary an adopted authority from user 'John'.
User 'Mark', who does not have the ALLOBJ privilege, executes the binary, and the process gains (adopts) all privileges from user 'John', so user 'Mark' can run the program with the ALLOBJ privilege.
This is how the SLIC part of OS/400 works (SLIC is the operating system kernel of OS/400, running on IBM AS/400 computers).
[Tell me if I got something wrong here, I'm not an OS/400 expert]
Granting privileges to users makes administration easier and it's powerful enough for almost any scenario; granting privileges to binaries makes it a bit more difficult but also more powerful, and i guess that's why it is the preferred method used by Trusted Operating Systems.