Slashdot Mirror
Graph of Linux Vs. Windows System Calls
cgrayson recommends Richard Stiennon's blog on ZDNet — a post titled Why Windows is less secure than Linux shows a compelling graphical comparison between system calls on the two operating systems. The blogger tips Sana Security for the images. Quoting: "In its long evolution, Windows has grown so complicated that it is harder to secure... [T]hese images... are a complete map of the system calls that occur when a web server serves up [the same] single page of [HTML] with a single picture."
Can anyone verify the accuracy of the "graphs"?
Interesting, they look hand drawn. I wonder if arbitrary complexity could be visually added by using a suboptimal drawing pattern.
Where is the Vista version?
The article is dated April 14th, 2006. Nice.
The photos are completely unreadable and mean absolutely nothing. Let's see the entire graph with labels so that we can know exactly what's going on during the calls. From that graph, for all we know, we could be looking at more than what they claim.
I just happened to think: Do you suppose it would be possible to refactor the Windows graph to make it look less tangled, or refactor the Linux graph to make it look more tangled? Imagine the graphs in 3-D space and being able to rotate around them or even view them from inside looking out in different directions. The concept is similar to adjusting the axes in the same manner as logarithmic paper can make some plots look like straight lines (once that concept is recognized then the math can become infinitely complex for defining the axes).
To be perfectly fair: How do we know that the researcher who created the graphs optimized both for clean and concise 2-D layout?
In response to my own question: No matter how you want to change the visualization the Linux graph looks to have far fewer multiple source intersection points and a larger prevalence of straight line heirarchical structure.
the NPG electrode was replaced with carbon blac
NO! This is a terrible, terrible misuse of information. The person who came up with those graphs should be forced to read "The Visual Display of Quantitative Information" Edward R Tufte until their eyes fall out!
IIS is written in C++.
Apache is written in C.
These graphs show the different calling models of C++ and C.
That is *all* they show.
Never have I seen papers or research that implies the number of system calls correlates to security. What's next, implying MS-DOS is more secure than Linux based on numbers of system calls and lines of code?
Comparing the complexity of system calls made by two different programs on two different OSes and then using that solely to judge the two differing OSes seems like an astoundingly flawed comparison. Seeing as Apache runs on Linux and Windows it seems pretty obvious that they should've used at least used the same program to make this comparison even slightly relevant.
I'm not saying Windows isn't worse than Linux in this respect, just that this article proves nothing.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
Well, not only that, but it has nothing to do with Windows and Linux. More like, Apache and IIS. You could run Apache on your Windows box, which I'm sure LOTS of people do.
The normal usage of syscall is something that has to transfer control to the system, from your program. Things like accept(), write() and sbrk() but not strcpy() or malloc(). While I haven't done an strace on Apache-httpd I have done it on my own webserver and I find it hard to believe that Apache-httpd is as bad as the graph in the article implies. And given there's no text in the graph it's hard to check.
At it's simplest a HTTP response is: accept(); read(); open(); fstat(); write(); sendfile(); close(); close();. A lot of servers will set options like: FD_CLOEXEC, O_NONBLOCK, TCP_CORK and call shutdown() at the end. You can also easily blow a few more syscalls on config. options which don't do anything for the simplest case, but the graph implies 50-100.
The confusing thing, to me, is that if by "syscall" they meant something like "library calls" then I'd expect much more for Apache-httpd (as large bits of code are in libapr etc.) ... but the comparison is worthless then anyway.
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
Yeah, its Apache on Linux and IIS on Windows, but what about Apache on Windows. What are the system calls there. If they are about the same from Linux to Windows for Apache, then all this proves is that MS wrote a crappy Web server. But if there are more calls to be made with Apache on Windows, then I would say that Windows makes its programs do more system calls and possibly makes all programs more likely to be cracked into. But its not fair to put one program against another on different OSs, then say the OS is the problem.
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
Twaddle. The report comes from a company that makes money selling security software for Windows. Scaremongering is good for their sales.
What would be interesting is an analysis of the types of system calls. What about a comparison of the functionality of IIS vs. Apache? Perhaps Windows provides some calls that Apache has had to implement in it's own application code. How many of those so called system calls trap in to the kernel?
This is just insubstantial FUD as far as I can see, backed up by indecipherable pictures.
In other words, number of system calls tells us nothing useful about security.
I don't know what you're talking about. In TFA it's quite clear that the top graph is Apache on Linux, and the bottom is IIS on Windows, both serving the same page. So there are two factors (at least) between them, a different OS and a different webserver. It's not fair, as much as I'd like to, to attribute the increase in calls purely to the design of Windows -- that would only be possible if it was Apache vs. Apache (and even then, there would be other things to control for).
If you accept that more system calls are inherently bad, than the graphs might indicate that "IIS on Windows" is less secure than "Apache on Linux," but it says nothing about Apache on Windows, or Windows as a platform inherently.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
> This is just insubstantial FUD as far as I can see, backed up by indecipherable pictures
So your assertion is that an overhead road map of cities, such as New York, NY vs. Kalamazoo, MI, would be entirely useless in generalizing points of traffic congestion and points of traffic collisions?
Maybe you don't design operating systems (computer or civil), or, if you do, maybe you shouldn't.
the NPG electrode was replaced with carbon blac
#1. Old news
#2. Apples and Oranges (IIS on Windows versus Apache on Linux? Which are we comparing?)
#3. Lack of detail: You can't see what system calls are really involved. No indication of configuration. No version numbers.
So that puts it in the realm of FUD, although the blogger does explain that its just a blog.
From my experience with Linux and Windows, the philosophical difference has to do with what is doing most of the work. In Windows a great deal of functionality is granted by the Windows API. As most programmers throughout the 90's know, Microsoft created their API around the functionality they needed for their own development, and then the rest of us had to buy the 'Secret' API manual with all the treats.
In Linux the Kernel where all those system calls go, is pretty limited compared to Windows. Where most functionality is added for developers is in shared libraries. Windows of course has the too, but its more a matter of where the real action is running. Is it in the kernel or in userspace. With Linux mostly its userspace, so there is less issues with software errors being capable of interfering with the machine itself. Still there are ways developers, especially of servers requiring some superuser priveleges (listening to ports under 1024) have provided security holes in basic interfaces (Sendmail and Bind for example). Still thats not reserved to Linux. Beyond that, we talk about the fact that Linux users don't run as root, but I have seen alot of irc session where the username of root is in the GID. So SOME folks do run as root. Whether the distributions now make that less necessary, that is also how Vista is going.
Apache is a bad project to compare other software too. It has been remarkably well developed both for stability and resisting sneaky security issues. Obviously one can muck up their configuration to reduce their security, but Apache itself (despite its initial moniker of being A patchy webserver) is a terrific example of well run coding projects.
IIS on the other hand is one of the posterchildren of security problems, with early versions not checking for navigation of parent directories, along with other trivial insecurites, based in some ways on permitting the developer to easily integrate IIS with other Microsoft tools.
So yes, IIS on Windows is more insecure than Apache on Linux. And Apache on Linux has always kicked IIS's ass in market share. I wonder if we compared Apache on Linux to Apache on Windows what we would find.
Not defending Windows security, but it's entirely possible that the graphical depiction is not "optimized" so that it intentionally looks like spaghetti. It's hard to see what's going on with the resolution given, but some of the call "bubbles" seem to be unnecessarily placed far away from whatever called them with a long strand of spaghetti between them. This isn't necessarily an indication of spaghetti or bad design, but a bad graphical depiction. Also, just because lots of places make a call to the same API (which causes the graph to look like spaghetti) does not mean bad design--to the contrary, it can be very good design.
I hate Windows as much as the next guy, but I'm not sure this is really a good case for why.
These pictures seem to show that IIS is much more tied in with the Windows OS than Apache is with the Linux OS.
I think that's credible, and that it illustrates that in case of Windows, the wider (and much more complicated) interface between applications and OS is real. I have no difficulty believing that this offers many more opportunities to compromise the OS, and hence is less secure.
He said 'syscall' right?
[ pasted from http://en.wikipedia.org/wiki/Syscall ]
System calls often use a special CPU instruction which causes the processor to transfer control to more privileged code, as previously specified by the more privileged code. This allows the more privileged code to specify where it will be entered as well as important processor state at the time of entry.
When the system call is invoked, the program which invoked it is interrupted, and information needed to continue its execution later is saved. The processor then begins executing the higher privileged code, which, by examining processor state set by the less privileged code and/or its stack, determines what is being requested. When it is finished, it returns to the program, restoring the saved state, and the program continues executing.
[ end paste ]
So, forgive me.. I could just be naive; but what does C or C++ calling semantics / methods have anything to do with calls into the OS? Seems like you'd have to make the same calls regardless of the language that you use, or more to the point, that the calls represent the facilities that the OS has made available to you. Seems pretty language independent from my readings.
KDE and Gnome developers also....lest XFCE surprise them both over time. More functionality is better, as long as the software is integrated in a sane way. The problem is functionality in the wrong places, not functionality itself. I think everyone here knows what harm the will to reduce functionality did to GNOME... (awaiting flames already
If it were that unsecure, why would it have zealots in the first place? Why would anyone stick with it? What about all those secure apache servers out there?
Good protocol can secure bad encryption more easily than good encryption can help bad protocol.
The Sana Security diagrams show us just how bad the windows internal protocols really are. There is no securing this system with Digital Rights management or any other encryption scheme. Any security method placed on top of a such bad messaging protocols will fail miserably because even if the encryption or other security suite is perfect... windows isn't. And the system will be compromised by drilling down through windows... not through the security system.
What good is a bullet-proof pad lock if you put the combination on a yellow sticky note next to the lock itself?
[signature]
I dont know I would say it has *nothing* to do with Windows vs Linux.
It is a map of OS calls required to accomplish a task.
Your point is good, though, a better test would be apache on windows
versus apache on linux.
emt 377 emt 4
"If it were that unsecure, why would it have zealots in the first place?"
it's called money, as in, people make money from what they know about it, and lets face it, ms was just lucky, followed by having smart (for them) marketing practices, and finally, having good strong-arm tactics.
No they don't. They show *system calls*, into the kernel, not method or function calls within the user-space program. The language shouldn't make much difference at that level.
So, forgive me.. I could just be naive; but what does C or C++ calling semantics / methods have anything to do with calls into the OS?
/. of "I'm going to seem smart by discrediting the article, and the easiest way to do so is make something up without reading the article".
No, you're right, it has nothing to do with C/C++. The GP was just another example on
The enemies of Democracy are
This shouldn't be titled why Windows is less secure than Linux. If the author actually had an integrity or an understanding of what he was writing about it should be title why IIS is less secure than Apache. Because I bet Apache running on Windows looks very close to the Apache running on Linux. Mostly because the Apache team has an excellent set of developers.
This blogger should be shunned out of the internet world as a worthless hack.
As well as wanting to know what the nodes represent (system calls or procedure calls?), I'd like to know what the edges represent. Control flow? Data flow? What are they supposed to be?
This article is unbelievable, apparently presenting a conclusion that the writer doesn't understand, using meaningless data.
>north
You're an immobile computer, remember?
If you assume that each system call is a potential vulnerability, and that less calls are inherently better
I think that's severely oversimplifying, because rewriting the system to take only one system call would certainly result in more bugs, no?
Looking at them both I notice the Linux one has a lot of empty space and draws the graph longer, and has a wider pixel size.
The Windows one is shorter and thinner.
Those simple differences make the Linux one look less messy, even if they ARE that simple.
I'm sure you could easily refactor the Windows one to look less messy. The real details though are in what those system calls are; and the two images provided are too small to SEE the names and routes of the system calls where relevant. Just looking at the tangle and counting lines is NOT a security audit.
The point is not perfectly on the mark, but it is not wholey off the mark either.
That's right. It's close enough to the mark that it looks like it's making a good point while masking the point that drawing any conclusions besides "this might be why Windows is less secure" is complete BS.
As to apache and iis as the choices, they have bearing in that apache will likely be the choice on linux, and iis will likely be the choice on windows.
Ahhhh, now might be a reasonable conclusion.
However, that's not what the article says. The article says "these graphs are why Windows is less secure", not "these graphs are why IIS/Windows is less secure than Apache/Linux" or even "this is why web servers on Windows are less secure than web servers on Linux."
And if iis has that much to do with the chart, then why is the graph *that* much more involved? Is it doing it's task inefficiently? Are the hooks for ASP or other things that numerous?
I don't know. It's not ASP, because they're serving the same page from both. At the same time, I can't imagine what all the additional system calls that Windows would need are either. Some investigation seems to indicate that the APIs are about the same, so why would you need more calls on one than the other?
The only other thing I can think of besides "IIS sucks" is that the Windows subsystem is making multiple syscalls for each library call. For instance, on a read or write the library hides the fact that sometimes not all the data is transfered by making multiple syscalls, while on Linux the kernel hides that fact. But this doesn't necessarily indicate a problem with Windows at all -- quite the contrary, it means that in that respect the Windows kernel is actually simpler because that logic moves to user space.
This blog is from some self proclaimed security specialist who is now a marketing guy, but from his blog post he obviously has no idea what he is talking about. The two graphs he generated tells you nothing. He says they are system calls, which again tells you nothing. The Linux/Apache graph appears more organized, while the Windows/IIS graph appears messier, but I bet you could shuffle things around and have the two graphs look nearly identical. But there's no labels on anything, we have no idea what the calls are, they could all be "strcmp" calls for all we know. And the assumption that a more complex graph means poor programming also implies that having everything done in one function (thus a super clean graph) means good programming, which is obvious fallacy.
So the script kiddies and know-nothing geeks on Slashdot all get excited about this graph and write things like "nah-nah M$ sux!" and "this explains everything, I am the smartest kid in the world."
And a very small number dismiss the blog for what it is, absolutely worthless.
But no rewriting the system to more specifically do the task in a more focused way would almost certainly result in a lot less bugs, of course the system would be less "generally useful".
Clearly it is a simple argument, less is more.
Backwards compatibility has huge costs, one of them is security. Supporting those apps with 8.3 filename limits, and 3 or 4 different ways of accessing the file system, all mean there is a lot more around to go wrong.
If you are actively using large chunks of "more" you probably don't care, as your system is more flexible, or more featured.
But I'm really not interested in the performance hits the more bizarre features of SMB gives to my webservers, but I daren't switch it off, as I know I'd be running an IIS configuration that is practically unique in the world, and it is flaky enough as it is. Similarly I don't care about that 8.3 compatibility, I know I could switch it off, but I'd worry something obscure might break. So I'm stuck with the "more" even when I want "less". Where as my Linux webservers don't have a GUI, most don't have SMB (or NFS), I lost all that network filesystem junk with the last update on most of them (scp (or http) will do fine for most things).
Guess it comes down to design - the secret of elegance is about what you take out, not what you put in.
And if you want (or are unsure if you need) binary backward compatibility to DOS 1 (or whatever level is provided), you can take out very little.
The reason the Linux version has a lot of empty space and wider pixel size is because... there are so many fewer connections between nodes. There is more room to represent them. If appears that while Linux does have nearly as many nodes, many more of the calls are in a linear fashion. This is good security-wise as you can get a better idea of what data should be passed through a particular chunk of code and can better plan for exception checking and out of bounds conditions so malformed data will be handled gracefully.
I'll never make that mistake again, reading the experts' opinions. - Feynman
Remember that your are comparing public results about a peer reviewed application against a development black box we cannot see into. Personally I don't think that is a very good comparison. Also I think they should have compared apache on both platforms.
Prove it. I dare you to put a freshly installed M$ system and a freshly installed linux box side by side outside your firewall and see which gets pwned first. My last attempt the XP box lasted precisely 24 seconds. Try it, it will be an eye opener...
...of how NT-based Systems are misdesigned are the security design and implementation in general.
For example, to get the current SID (Security Identifier, "user id") of the current process on NT, one must:
* Open a handle to the current process
* With that handle, open a handle to the process token of the current process
* Call GetTokenInformation with a NULL pointer to query the length of the data it would return
* Allocate memory for a buffer receiving Token Information
* Call GetTokenInformation again with a pointer to that buffer
* Resolve a pointer in the data received to get the SID_AND_ATTRIBUTES structure
* Resolve a pointer in that structure to get the actual SID
The length of the SID is unknown, so to compare two ore more SIDs, one must use additional library functions
After using all that information, don't forget to close all the handles and to free the memory you've allocated.
NOW THE SAME THING ON UNIX:
uid_t myUID = getuid();
ONE line of code. Guess on what platform you can mess that up easier.
Or another example:
===================
As a privileged user, create a file in a certain directory.
On NT, you need SeTakeOwnership, SeRestore and SeBackup privileges.
You can't use existing applications, because CreateFile() / CreateFileEx() will fail, even when you have the privileges enabled. You have to write your own application, which uses the FILE_FLAG_BACKUP_SEMANTICS flag in these API calls, so the privileges will actually be used (well-designed operating systems use a unified method called privilege bracketing instead of different flags for every system call).
Now you could theoretically create the file regardless of the ACL, IF THE DIRECTORY ALREADY EXISTS.
If the directory does not exist, you have to create the directory first.
Unfortunately, CreateFile() / CreateFileEx() can OPEN directory handles, but you can't create directories using these APIs. But the API for creating directories does not have a FILE_FLAG_BACKUP_SEMANTICS flag, so the privileges are ignored, and you can't create the directory, if you don't have access because of the ACL of the parent directory.
So, what are you going to do?
One solution would be the following:
* Open a handle to the parent directory
* Backup the current security descriptor of the directory
* Initialize a new security descriptor for the directory
* Place your own SID into the security descriptor as owner (see above on how to get your SID, it's a lot of fun)
* Initialize a new empty discretionary access control list
* Initialize a new access control entry with your SID and a full-access permission
* Place the access control entry into the discretionary access control list
* Place the discretionary access control list into the security descriptor
* Write the new security descriptor to the directory
* Then CLOSE the handle and REOPEN the handle to the directory (with different access flags)
Now you can create the file. After you've done that, undo the operations above. If the program gets killed while you're doing that, you have messed up the ACL of the parent directory (because this method is not transaction-safe).
This is maybe the WORST API design I have ever seen.
If you want to do the exactly same thing on, for example, Solaris, you just enable file_dac_write and file_dac_search privileges (from the permitted privilege set into the effective privilege set), create the directory using mkdir() and the file using creat().
No need to write your own program, Solaris has utility programs to let you change the privileges of your shell. Even if you write your own program, privilege bracketing is much easier on Solaris than on NT, although the Solaris privilege model is much more powerful than the one of NT.
=============
There are numerous examples of that sort.
This is why I am totally convinced that NT is a poorly designed operating system. There is no unified API. One system call works c
1) Interestingly enough, the grandparent post was a Linux troll, and you responded about MS.
2) Whether or not you like MS (and i don't really, though i grudgingly call them useful at times) they weren't really lucky. They seized opportunities others didn't see, capitalized on other's mistakes, relentlessly focussed on how to usurp their competitors and steal their customers, saw the value of network effects and also leverage their dominance in one area to another. None of it was real luck. Though he likes to think of himself as a technical genius (which i don't really) Bill Gates really is a business genius, a true shark amongst techs without business acumen, and used it to amass a huge fortune.
MS strongarm tactics require them to have a market dominance in some field. At one time, MS was just another company, smaller than Lotus and others. Yet they grew to where they now can use strongarm tactics. They bought code from others, polished it, made it work together very well (to the exclusion of others) and make a lot of money from that.
As far as marketing, their consumer marketing really sucks. Seeing an ad saying "WOW" really isn't making me want to buy Vista. The dinosaur ads really don't make me want to buy Office.
If the Linux desktop is to succeed, they will need to take an honest look at how MS succeeded, and how to counter that. When MS saw a market dominated by a competitor (Lotus) they looked at every reason why someone would stay with Lotus and came up witha counter, when most Linux geeks look at MS market dominance, they say "luck" or "marketing" and just sit and wait for people to somehow realize Linux is technically better and then sit and wait until everybody switches.