Q: Hi I read the following article (http://news.com.com/2100-1002_3-1025273.html) on a Windows vulnerability, and I was wondering if Linux has the same problem or how it is about solving that problem
The cause of the problem is that every application can send a message to any other application on the same desktop, “said Paget, now a senior security consultant with Next-Generation Security Software.” When the target application receives a message, it has no way the critical question of whether the message is sent by the system or by another process
How a Linux process is doing to communicate with one another Linux process that a message is sent to it from root or regular user?
Thanks for the comments,
pitupepito
Best Answer: Ubuntu, the community support is just excellent.
1. You won't need AV.
2. You can use the internet to install the codecs, then you don't need the internet. Try rhythmbox and vlc media player.
3. The config files for the system certainly aren't written in C, so that won't help you. The source code for the Linux kernel is available, but it will blow your mind if you are a beginner.
Re:Well looking it up works too
Re:Always nice when someone outlines the relevant facts instead of just telling you to look it up.
Re:Originally posted by: guy
Thanks, BBWF – very informative.
Re:Thanks, BBWF – very informative.
Re:Ok people, calm down
Back to one of the original questions (which I also didn't see when I first read the thread):
Originally posted by: guy
How does a Linux process do to communicate to another Linux process that a message is sent to it from root or a regular user?
This is what's known as inter-process communication, or "IPC." There are 3 (maybe 4) different methods commonly used on unix (including linux).
The first and most simple way of sending messages to process is via signals (try man 3 signal and man 7 signal). Signals carry no data, so they're no good for data transfer, but they're good for telling a process "hey, XYZ type of event happened." Signals all have names, and are named SIGSOMETHING where SOMETHING is a very short (2-5 letters or so) description of what the signal is for.
The signal everyone is probably most familiar with is SIGINT, which is what gets sent to a console program when you hit control-C. SIGHUP means "hangup" and for daemons, usually prompts a re-read of configuration files. The "original" (I think, anyways) meaning of hangup is that the parent process (often your shell, due to you "hanging up" your modem in the old days perhaps) has exited, and thus many apps exit when they receive SIGHUP. Some other common signals are SIGKILL, which kills a process on the spot, SIGSTOP (control-Z in a shell), which pauses a program and sends it to the background (and its counterpart SIGCONT which wakes a process back up), and SIGWINCH, which tells an app that the terminal size has changed (this is how console apps resize themselves when you resize your terminal).
All signals can be caught by programs except SIGKILL and SIGSTOP. Programs often catch SIGINT to clean up before they exit, or catch SIGWINCH to resize themselves accordingly. The kill(1) program is what you use from the command line to send signals. You can send any signal you want with kill, but without specifying one it will send SIGTERM (which is essentially the same as SIGINT/control-C).
As far as I know, signals can only be sent to a process by its owner, or the superuser.
The second method of IPC is via fifos. Fifo means "first in, first out." Fifos are also known as "named pipes," because they're like a pipe, but with a filename. Following the concept that "everything is a file," security with fifos just relies on whatever permissions you have given them via chmod/chown/chgrp. Pipes are a bit odd in that you can play with them on the command line like files, but they are blocking, like sockets. Open up two xterms, in one, do mkfifo foobar; echo hello > foobar. You will notice that your shell just sits there waiting; that's because fifos block — they have to wait until the data has been read before they can return from writing it. Now in your second xterm, do cat foobar. You will see hello come out of that end of the pipe, and your first xterm will now have returned to a prompt. Weird.
Third are sockets. Sockets were created for easy network communication, and can either exist as network ("inet") sockets, listening on a port (any network server like apache or sshd would be an example of this), or as a file (a "unix domain socket"). Network sockets basically have no security; they're listening on an address/port combo and whatever the network slings their way will be taken in. Of course that's what firewalls and all that junk is for. 
Unix domain sockets are just files on the filesystem, and normal file permissions apply to them.
But of course, a socket listening on the network is not an inherintely insecure thing, you just have to make sure that the program itself is secure. sshd will accept a connection from anyone, but that doesn't mean that someone connecting to your ssh server can cause much harm.
The "maybe" fourth method is the X windowing system (X11, Xfree86, etc), which is not always on a unix system, but it is on many. X is more of a hairy thing to understand than the other things I mentioned. The only real method (that I know of) of communicating between X apps is by setting X "atoms," which are essentially global variables available to all X apps on a given server.
So for the most part, you can't do anything to hurt another process unless 1. you are its owner, or 2. it is written badly. If neither of those is the case, you are generally pretty safe from wreaking havoc on other processes. Unix security model rocks.
Re:You don't get it. According to the news article, this class of problems has nothing at all to do with credentials. I haven't read technical information yet though, but I understand Windows programming enough to grok the layman's explanation.
So even if you ran a hardened Windows 2000 box, for example, a poorly-written application could still have a vulnerable window messaging queue.
And furthermore, everything does not run "suid" in Windows, unless you specifically refer only to Windows 9x, which is deprecated anyway. guy explained in fewer words than I can why even with the NT security model enforcing credentials, why any class of exploits against a Windows service could still be devastating (not just this kind, which claims to transcend credentials completely).
But go ahead and argue vehemently and wave the Linux pom-poms all you want.
Re:In windows programs run at whatever level they want to so it's EQUIVILENT to being suid in windows HENCE THE QOUTATION MARKS.
Not really, Windows programs run with the credentials of the user running them. The problem is most services run as SYSTEM and they create atleast 1 window handle which means they can recieve window messages and be exploited to give that user SYSTEM level credentials.
Re:Originally posted by: guy
Well if you read the article, it explicitly says that runtime credentials have nothing to do with the problem. I also firmly disagree that all Windows apps run "suid" root. They may typically run with Administrator credentials, but they don't have to (they do because Win 9x has no security model, and because Win XP defaults to Administrative instead of Limited user accounts). That is not suid root; that is for all intents, root. AFAIC, there is no proper suid in Windows ("Run As" is rather flawed).
So your lengthy diatribe completely misses the mark.
The problem is that the event-driven messaging programming model inherent for all Windows applications can be a conduit to vulnerabilities.
Event driven programming isn't exclusive to just Windows, but I don't believe this problem is universal on other operating systems.
Of course windows has no "suid". I was just trying to illistrate the differences.
In windows programs run at whatever level they want to so it's EQUIVILENT to being suid in windows HENCE THE QOUTATION MARKS.
And event driven programming or whatever you want to call it, is needed for any OS that has programs that need to communicate with other.
In Linux programs only run at the level that you need them to run. IF YOU DON'T EXPLICITY ALOW PROGRAMS TO RUN AS ROOT IT IS IMPOSSIBLE FOR THEM TO MAKE ANY IMPACT ON THE REST OF THE OS. (other then using up resources, like filling up your home partition or using a percentage of cpu time..) which is the point I was trying to make and you missed.
For example If I had a browser like IE that has numerous security flaws in it's design that can allow anonymous websites to make me download and install programs without my knowledge, and I download and install a program that causes pop-unders that cause adds to pop up whenever I visit a website. This may affect me or any files or other programs I am running, but if someone else logs into my computer using a different user name they will never be affected by this, unless I run as root.
SO, linux is immune to this vunerability in windows, just like it is immune to about 90% of the security flaws that plague windows. Windows is designed for convenience, it's designed to get things done easily and with little user involvement as possible. In linux this is secondary over a security and stability, that's why it seems that it is much harder to use, because it requires your involvement in various things to prevent problems.
Re:The biggest problem is trying to explain the difference is that you are essentially comparing apples and oranges. Asking whether linux suffers from a particular flaw that another OS suffers from is like asking if a pet can catch illnesses from you. Some very few diseases can cross species, but the vast majority are confined to a particular species or perhaps genus.
BTW I think a discussion about pipes would be more appropriate.
Re:Well if you read the article, it explicitly says that runtime credentials have nothing to do with the problem. I also firmly disagree that all Windows apps run "suid" root. They may typically run with Administrator credentials, but they don't have to (they do because Win 9x has no security model, and because Win XP defaults to Administrative instead of Limited user accounts). That is not suid root; that is for all intents, root. AFAIC, there is no proper suid in Windows ("Run As" is rather flawed).
So your lengthy diatribe completely misses the mark.
The problem is that the event-driven messaging programming model inherent for all Windows applications can be a conduit to vulnerabilities.
Event driven programming isn't exclusive to just Windows, but I don't believe this problem is universal on other operating systems.
Re:Basicly it goes like this. If you are using a program that has a security problem, it's only going to affect you, your programs, and any files you own in a worse case scenerio.
Say you downloaded and ran a linux virus.. (if you have a new version of linux.. Anything new in the past year or two, you don't have any viruses to worry about.) And this virus was designed to corrupt files, then it can only corrupt files you own. That's why you don't run as root or superuser unless you have to… Everything else will be immune to the infection.. any other users and system files won't be affected.
This is because any programs you run can only do what you can do. If you don't have rights then neither do the programs you run. THe one blaring example is suid programs. These programs will not run correctly unless they can access restricted parts of the OS/hardware. So for example X windows needs to access hardware in order to run, so parts of it have to pretend to be running a Root. Suid programs should and are kept to a minimum and are continuasly tested to make sure that they are safe and secure….
So no, this couldn't happen in Linux, unless something very remarkable was going on… which won't happen. Programs you run on the desktop cannot send system calls to other programs, they can only send calls that run under your authority. Just as long as the programs aren't sent to run in suid.. which 99% of them are not. As long as you keep your system up to date your about as secure from viruses and exploits as much is possible.
Windows this is a bigger issue because everything runs "suid". That's to make things easier and how the system was originally designed.. You only had one user. Newer versions of windows allow real user accounts to be set up, but due to the design if any one proccess becomes comprimized they probably have access unfettered access to your computer in some fasion, usually to install addware software or corrupt files or to simply copy itself and have you mail it to all your freinds and family, or associates you have in your address book. The divisions are tacked on on the top "user" end of the OS, if you can get past that layer, then your have control of the OS. In linux this division carries all the way down to the core part of the OS, the kernel… With exeptions of the suid programs that need special access to run properly…
It's not perfect and there are always going to be bugs and such, but they get fixed quicker and are more easily controlled then Windows.
Re:Best part is M$ can't fix that because it would break every program (well most) that run on windows. IIRC they decided to call it a design feature. Anyway, *nix uses a different security model and dosn't suffer from that particular problem.