Modifying the sudoers file was only one example use for this. It allows you to write to any file that is normally only writeable to root. Modifying sudoers is a fairly simple and visible change, but modifying one of the system startup scripts that launchd runs as root would work just as well. I think it only lets you append to a file, but it would also be possible to temporarily modify sudoers, then set your worm's setuid bit and change the owner to root, then revert the sudoers change. The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?). Of course, once you are root then you can do things like modify firmware and boot settings and hide inside the kernel...
Spot on. If I was a bad guy (I'm only a little bad) this is *exactly* how I would create an attack.
The only user-visible thing would be the setuid bit on a suspicious binary hidden somewhere in the system (how many people check for this?)
That part in particular highlights the problem with setuid.
It is, in effect, a deliberate hole in the security boundary: The mere existence of the setuid facility means that you can *never* audit the security policies (access rights) and be confident that they truly reflect the rights and restrictions of users.
Auditor: "Who can access this file"
Admin: "Easy" (ls in the directory), "User1 can write and users in the group "group1" can read it.
Auditor: "And no-one else can read or write the file, not even root?"
Admin: "What do you mean, of course root can read and write the file, root can do anything. This is Unix, d-oh!".
Auditor: "Ok. Who can run as root, then? I need to have an exhaustive list, you see. The insurance company needs the list to assert the risk and calculate the premium"
Admin: (sighs, looks up in sudoers and su) "The user admin1 and users in admingroup1 can run as root".
Auditor: "And no-one else can run as root? What about that setuid bit I've heard of?"
Admin: "yes, ok, a setuid root utility can run as root, I knew that. But I have those covered. I run a report every week which lists all of those utilities with the setuid bit that are owned by root. We accept only those utilities that we know. Trust me"
Auditor: "Ok then. So back to this file, how can you document to me that - say - this 'cmsagent' utility cannot access the file, now that we know it is setuid root?"
Admin: "What do you mean, I installed cmsagent myself, I'm pretty sure that it only allows remote users to access documents in the CMS system"
Auditor: "But how do *I* know that? The operating system does not protect the resource against root abuse?"
Admin: "No - this is Unix. I know what I am doing. Trust me. I have access to the source code, if you want to see what it can do".
Auditor: "Ok. I don't know how to read code, so I need to have one of our code auditors look at all the source code then. Assuming that, how do I know that the binary present on this system is the compilation of the source code you will give me?"
All of this because of a bad design decision. In other operating systems (with no all-powerful root and no setuid), the DACL of a resource *does* reflect who can access the file.
SELinux, apparmor etc are ways to add (yet another) security context with proper security boundary.