It's not a Feature, It's a Vulnerability!
pmeunier writes "Apple's security stance is stunning. In the latest (10.3.9) update, Apple removed two capabilities because they pose security risks. One of them is the capability to run setuid and setguid scripts (the other was actually unused). Can other commercial OS vendors (how many are there :) adopt a similar stance? Will you be inconvenienced by the inability to run setuid scripts on MacOS X? Which other features/capabilities (in any OS) would you like to have removed?"
I guess I missed what was "stunning" about this.
Information wants to be anthropomorphized.
It's all about looking at the trade off of system security vs. robustness. I don't know about SetUserID but if it makes my Mac less secure and doesn't allow my applications to do anything I need them to then shut 'er off.
The OS is already built with abilities to SUDO applications so perhaps Apple will figure out a more secure way of implementing the SetUserID feature so as not to create a vulerability. If they have to have it, then it probably needs to a an Admin level tool anyway.
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
Personally, this doesn't affect me, but I see it as a reasonably smart move. Really, the only 100% effective way to seal a vulnerability is to take away whatever caused vulnerability in the first place. I'm sure there's a workaround so you still have the same functionality with some other, more secure, method.
Then again, I've never used this, I have no idea what I'm talking about, and I'm just exercising my Slashdot right to be opinionated!
Elmo knows where you live!
hmm.... while setuid is often used as a bad hack to avoid learning proper programming methodology ( like priv sep ) I'm not sure i like that they've taken it away completly. I prefer freebsd's approach ( but then... how often is that not true ? ) of making you mount the file system with a 'setuid' flag before you can run setuid scripts on it. since most apple users will never touch fstab ( or whatever their xml equiv is ) this would be a better approach.
Sitting Walrus Blog
Now as an added bonus, look in your /bin directory and tell us which scripts have suid turned on. Now look for the suid bit on every file in your filesystem.
It won't be very easy to find the programs without a 'find' command.
Note that the only difference between a regular file and an suid-bit file is a teeny one-bit change-- there's an 's' instead of an 'x' or '-'. It's hard to see, and many people don't know it is when they see it.
Is that the sort of 'needle in a haystack' obsfucation that introduces all sorts of security issues.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
Something to think about is that anyone with root (on a Unix-esque system) can make a system insecure. This doesn't just apply to Unix, however. Anyone with super-user access to a system can demolish the security of any operating system, however. There are just too many things that can be done to leave nearly any system wide open.
There are also more than a few reasons to intentionally make a system insecure. Perhaps the system is part of a trusted network, with limited physical access. In that case, system security does not really matter much. Security also didn't matter much when the Internet/DARPAnet was designed -- a time and place issue.
While eliminating SUID/SGID scripts is probably a pretty good idea, I definitely want to retain the ability to make my own assessment of security and make the requisite changes to my system. Maybe there's a really good reason to have a TFTP, RSH, or Telnet server on a system.
Like I said, removing SUID/SGID scripts is probably a good thing, but I definitely want developers to be as cautious as possible in how they remove features. Perhaps rather than completely removing certain features, they should be disabled by default. My fear is that if this catches on with other developers, we could end up with quite a few systems like MacOS pre 10, where there is a definite lack of configuration (and hacking) options.
Don't get me wrong, I'm not bitching. Rather, I'm simply pointing out how this can go awry if it's unchecked.
-Turkey
they do, clearly. There are just too many examples of features dropped between releases of operating systems to pick only one.
Will you be inconvenienced by the inability to run setuid scripts on MacOS X?
no. It was a mistake that the feature was ever included. You should SUID/SGID binaries, not text files or anything else. Scripts are not binaries.
Which other features/capabilities (in any OS) would you like to have removed?
Can I vote for eliminating the ability of any OS to create annoying, non-standards-supporting web pages that use too much Flash and/or Javascript ? Can I prevent any OS from sending out spam email ? Can I remove the ability of a compiled application to crash the machine? No? Too bad. In any given system, there are a lot of features that aren't really needed and can be either a source of confusion or a source of problems. Most of these shouldn't be in the OS layer, and ( like the SUID issue ) should be tightened up if they are in that layer.
Fundamentally, though, the SUID/SGID thing referenced in the story is a non-issue. If I have console access, typing "sudo" and a password isn't even an inconvenience. It's already been pointed out that this feature has already been removed from almost every other major Un*x variant, including Linux.
1. It's not an important feature.
2. Even when it's used for what it's there for, it's being misused.
3. No competent sysadmin counts on it being there. Ever.
4. Most "real" flavors of *nix threw it away a long time ago.
If Apple is open to criticism, it's for not chucking it sooner.
Apple added a kernel switch for suid/sgid on scripts, and leave it off by default. If you want suid/sgid scripts on your system, enable them. If you don't think this comment has given you enough information to enable them, you shouldn't be running suid/sgid scripts.
echo 33676832766569823265328479713269.8639857989Pq | dc