Slashdot Mirror
Linux and the Smile.D Virus keeps us Smiling
pstreck writes "News Forge is running a humor filled satire on the the recent Smile.D cross platform virus. It's a good read and just another reminder of why that other operating system needs to figure out a new security policy."
There is a whole privelage system there, unfortunately, it can't be used by many people right now because of some brain dead applications. Quite a few programs won't run as anything other than administrator. Over time, once the apps get replaced, Windows will have a more viable security system, which will hopefully prevent many of these types of problems.
Linux and the Smile.D Virus keeps us Smiling
That pun would work better if it was actually called the Smile.D Virus.
Symantec and ZDNet appear to call it Simile.D.
NT has privileges (so users don't need to be
root to do certain operations), access control
lists for all objects, more than 32 groups for a
user, impersonation (so a server can take on the
identity of a connecting user and do operations
on their behalf).
Actually, Windows' privilege model is quite ineffective. Many privileges control the LAN-Manager, not the OS Kernel itself (eg. "Create permanently shared objects")
There are privileges like "Control Auditing" - but there is nothing like "allow this process to only ADD audit records to audit files" or "allow this process to only READ audit files".
There is also nothing like "Allow restricted IOCTL calls", "Allow mount/umount".
Windows grants all privileges to users, not to the binaries in the file system. A process can not spawn a more privileged subprocess, because Windows does neither support setuid/setgid, nor does it suppport privilege sets for programs in Windows' file system. All these facts make the Windows privilege concept rather ineffective.
There are _much_ better concepts than the ones found in Windows - maybe take a look at IBM's OS/400, or at Argus Systems' Pitbull Foundation, which implements an even stronger Privileges/Authorizations concept.
On an Argus box, you could, for example, add the PV_FS_MOUNT privilege to the authorized privilege set of some new mount tool binary on your harddisk, and then add the MOUNT authorization to the privileged authorization set of the same binary.
(Maybe set FSF_EPS if the program does not know how to handle privileges)
When a user executes the binary, the operating system would only put the PV_FS_MOUNT privilege into the effective privilege set of the spawned process, if the executing user has the MOUNT authorization (and if the PV_FS_MOUNT privilege is in the limiting privilege set of the process, which execs the binary - commonly the user's shell).
A user without MOUNT authorization could now display a list of all mounted file systems, but he/she could not mount or unmount Filesystems.
Even a user WITH MOUNT authorization could not mount/unmount file systems, if his/her limiting privilege set has been downgraded and for this reason does not contain the PV_FS_MOUNT privilege any longer.
---
YES, we NEED more powerful privilege concepts in Linux (and in ALL other Standard UNIX systems as well), to protect the OS from privileged daemons which get hacked for some reason.
(And this is also the reason why OpenBSD ist NOT really a secure OS - it highly depends on the fact, that only bug-free daemons have root privileges. A really secure OS would not grant any daemon something which is as powerful as root privileges just to open a privileged port or to use some funny special system calls)
Currently, only Trusted Unices offer strong security - however, most users do not need labeled information security (as defined by TCSEC B1), which is rather difficult to administer.
There should be some "light" version of a Trusted Unix OS without Mandatory Access Control (and maybe with a more simple set of privilege) for normal users.
regards,
octogen