I just upgraded to 5.2.1, and it still works the same way. Maybe your kernel is returning a different error code. Not sure which error code is correct.
At the very least it still comes down to rm -rf/home/user (Worst case) versus fdisk, format and reinstall.
I don't know about you, but if I've been compromised at a user level I'm not going to trust that that's as far as things went. I'm going to fdisk, format, and reinstall.
It still comes down to your logs remaining intact so that you have a chance in hell of tracking the offender.
I'm not all that interested in tracking the offender, and I suspect the average computer user is even less interested than I am.
It still comes down to possibly noticing that files are popping up in your home directory or/tmp that shouldn't be there. Sure you might not notice the extra activity, but you're a lot more likely to notice stuff going on in your user space than elsewhere on the system, especially once steps have been taken to hide their tracks.
Seems quite unlikely, especially for the average computer user, but I suppose it's slightly more possible.
Son, I've been doing security when you were in diapers.
Maybe your techniques made sense then.
Of course you can have a virus or trojan that runs in non-privileged space, but the scope of the attack is greatly limited.
Not on a single-user system it's not.
You can't compromise system files without first finding a local root exploit
So what? You don't have to compromise system files to make a serious exploit on a single-user system.
Every step that you cut out of the process raises the danger not only to your personal information but also every other person on the net.
If you're running a single user system, then your regular user account has access to your personal information, can bind to any high port, and can make a connection to anyone on the net. That covers just about every exploit already out there in the Windows world.
software upgrades are run in the background with appropriate privileges by cron, etc
And how does one get a software package into such a directory to be run by cron, etc?
PS, don't worry -- we don't hire people who log in as root here. I administer the boxes -- and I almost never need to use root.
If you can administer a box while almost never needing to use root, then I highly doubt your box is any more secure than your admin account. Administration requires admin access. Now maybe you've given such access to non-root accounts, but that seems more likely to bite you in the ass than just running as root in the first place.
Its not possible on a normally configured *nix box for a virus running as a normal user to reconfigure the OS and harm anything but that user's files
Even if this is true (it's arguable as most "normally configured" *nix boxes have root exploits), saying that a virus can't do certain things is not at all the same as saying that you can't have a virus.
arguably a big problem in and of itself
And that's the argument that I'm making.
Rootkits, the primary plague on *nix boxes depend on being able to get root on your computer to work properly (duh).
They also require the/bin directory not to be on a read-only volume, or for root to be able to remount the volume writable, which can't be said of a well-secured *nix installation.
all softwares remains in beta stages until they are abandoned. This is because bug-fixing and feature-adding are on-going processes, and are never fully completed.
I'd say once a beta has been out there for a while and there are no open bug reports remaining it's safe to call a release final. I wouldn't count feature requests, they shouldn't be responded to in the same branch once it has been declared beta anyway (some would say alpha, which is nice in theory but usually some minor features are added even after declaring an alpha release).
It is possible, as root, to load code at runtime into the kernel that is totally invisible to anyone poking at the computer.
Under linux, with kernel modules, this is possible. Even without kernel modules, it's possible to do it upon the next reboot (in Linux, under any distro I know of that doesn't run off a CD or other non-writeable filesystem).
I guess my lack of attention to this detail comes from the fact that I learned unix on FreeBSD, and in FreeBSD you can set the immutable flag on the kernel so that no one, including root, has permission to modify it. In order to remove the immutable flag, you have to be running in single user mode. It was actually just today that I came to the full realization that most Linux distros don't do this, and as far as I can tell it isn't even possible to do it on Linux.
My SOP for dealing with weirdness is to log into a console and run top as root. If I always ran as root, the spykit could be completely invisible. If I typically ran as user, then I'll see something weird.
OK, but you know what you're doing. The average Joe isn't going to. And if you've already noticed the weirdness, I would assume you're going to continue exploring further and further until you eventually find the culprit, even if that means booting from a CD and reinstalling everything.
They can't change root's LD_LIBRARY_PATH. That's the whole point of having multiple users.
It just seems to me that as you increase the number of things that you need root access to do, you also increase the ease with which an attacker can get a user to run a trojan. After all, if one needs root to install most programs, then a user isn't going to think twice when running an installer for a trojan which tells them to use sudo or su or whatever. And then, when it comes down to you and me, well we always check the MD5sum of the program before we compile and install it, whether we're root or not, right?
In my opinion, in order to properly protect an end-user from himself you need a whole paradigm shift. Firefox shouldn't run as root, but it shouldn't run as "anthony" either. Firefox should run as "firefox". And it should be installed as "firefox". Now there's something which can actually protect your data when you accidently click on a link to a website which exploits a hole in firefox. On my server system I've set up these "package users", although perhaps ironically, my only login to the system is root (it makes sense to me, because I only log in to the system to perform maintenance on it).
I wasn't arguing that it was necessary to be root in order to spy on someone. It's just that it's possible to do a better job as root.
You haven't presented anything better that you can do as root. There might be more ways to do the same thing, but that isn't any better.
Security isn't about absolutes, it's about taking precautions.
Security is about making the cost to an attacker breaking the security more than the worth derived by the attacker (although at low costs you have to remember the worth to some attackers of simply enjoying screwing up someone's system). I just don't see how running as a non-root user puts you over the top. Sure, if you run as non-root, and everyone else runs as root, then you're probably safer just because the most widespread scripts are going to be targetting others, but this just seems to me like security through obscurity.
No, they can't. Well, that's not quite what I mean. They could alias ps to/home/foo/.trojan/ps, for the low-priv user. Thing is, when Joe User calls his nerdy cousin Dwight up because his computer is slow as shit, and Dwight comes over and logs in to the console as root, typing/bin/ps aux is going to show the trojan running.
What if they changed the LD_LIBRARY_PATH?
Really, the best solution is for no one, including root, to be able to change/bin/ps. I believe BSD supports this through the immutable flag. In order to change a file marked immutable, you have to boot into single user mode.
You must not be aware of the basic function of most rootkits.
No, I'm just aware that the rootkit will change as the standard usage of the system changes. If lots of people had desktops running linux, then we'd see much different types of attacks.
The point is that with super-user access the attacker has the ability to replace _any part of the system_ with specially crafted versions the component that will hide their presence.
Well, maybe, and maybe not. I thought some unix OSes allowed you make some filesystems read-only and disallowed even root from remounting them.
This means that you can't trust the output from ANYTHING. They can easily replace things like 'who' and 'ps' so that their logins and processes don't even show up.
Right, and if I change the.bashrc to put my directory in your PATH ahead of all the others, then I can do the same thing. Or do you usually type in/bin/ps?
On a well designed system with good defaults it really isn't as easy as you might think. Certainly not impossible, or too challenging for someone who really knows what they are doing, but most attackers are script kiddies that just run stuff written by someone else.
And what is such a script kiddie going to do that can't be done without root? Hell, what is someone going to do with complete root access to my machine anyway? Steal all my bank account passwords? All they need to figure out is my gmail password and they've got access to all my bank accounts anyway. I guess they could find out something embarrassing about me which is stored somewhere on my computer and use it for some sort of extortion. But that could be done with regular old user access.
I thought about going with wireless internet. For $80/month it wouldn't be such a bad deal, since I'm already paying $65/month for DSL and a useless phone line. The problem is that my girlfriend uses the DSL, so I'd have to set up a router to the wireless connection, and it'd probably be too slow if we are both using it at once. Even then though, if I could be sure that the service had good reliability and that I could set up a router relatively easily, maybe I should go ahead and make the switch. I'd definitely take a speed hit, but that would be worth it, and I wouldn't be able to ssh in from work or other locations, but if I could get wireless internet on my PDA I wouldn't really need to ssh in from these places any more.
not to mention the fact that having to use root password to do so many things is a pain in the ass and causes users to get too used to just typing in their password without knowing what they are doing
Absolutely. I'd be fine with having a root and a non-root account on my desktop machine if the root account were basically never used. Essentially make root access needed as often as access to the bios, and make it just as hard to access. You can't do it by typing in a password, to access the root account you have to physically reboot the machine. Now that would be secure. Anything else is just a false sense of security.
you're completely failing to take into account that running in a priviliged account full time is what makes things like virusses and trojans possible in the first place
So you are claiming that it's not possible to have a virus or a trojan which runs as a non-privileged user? Sounds like you're the one who has no clue.
The difference is that not only are you prevented from taking steps to protect your data (storing it in protected DBs or under different, secured users)
Well, I don't store that kind of data on my desktop machine in the first place. I store it on my server, which in my opinion is the only real way to protect the data in the first place. It's just to easy to get root access on a machine once you have non-root access.
but the attacker would also have a significantly easier time effectively hiding his or her presence on the system. You might not even know that your account was compromised.
I don't see how this is true. When was the last time you checked your.bashrc?
The point is that allowing them such easy root access just opens up a incredible number of possibilities for the attacker.
I never said getting root access was easy. To get root on my desktop machine you'd need physical access to it. To get root on my server, you'd need my unencrypted private key.
Slashdot Mirror
I just upgraded to 5.2.1, and it still works the same way. Maybe your kernel is returning a different error code. Not sure which error code is correct.
Thanks, I added this comparison to my bookmarks :).
At the very least it still comes down to rm -rf /home/user (Worst case) versus fdisk, format and reinstall.
I don't know about you, but if I've been compromised at a user level I'm not going to trust that that's as far as things went. I'm going to fdisk, format, and reinstall.
It still comes down to your logs remaining intact so that you have a chance in hell of tracking the offender.
I'm not all that interested in tracking the offender, and I suspect the average computer user is even less interested than I am.
It still comes down to possibly noticing that files are popping up in your home directory or /tmp that shouldn't be there. Sure you might not notice the extra activity, but you're a lot more likely to notice stuff going on in your user space than elsewhere on the system, especially once steps have been taken to hide their tracks.
Seems quite unlikely, especially for the average computer user, but I suppose it's slightly more possible.
Son, I've been doing security when you were in diapers.
Maybe your techniques made sense then.
Of course you can have a virus or trojan that runs in non-privileged space, but the scope of the attack is greatly limited.
Not on a single-user system it's not.
You can't compromise system files without first finding a local root exploit
So what? You don't have to compromise system files to make a serious exploit on a single-user system.
Every step that you cut out of the process raises the danger not only to your personal information but also every other person on the net.
If you're running a single user system, then your regular user account has access to your personal information, can bind to any high port, and can make a connection to anyone on the net. That covers just about every exploit already out there in the Windows world.
I checked. My version of rm is from coreutils-5.0, and the applicable portion of code is in src/remove.c:
/* [comment omitted] */
if ((errno != EISDIR && errno != EPERM) || ! x->recursive)
{
error (0, errno, _("cannot remove %s"),
quote (full_filename (filename)));
return RM_ERROR;
}
Linux is returning EACCES. I'm not sure if that's the proper behavior or not (man unlink doesn't talk about the immutable flag).
Root can read any directory on the computer, and since the scripts to do the updates should be installed by the vendor, your first question is moot.
If all you want to run is programs provided to you by the vendor, perhaps.
You don't administer many solid boxes do you?
Not using Fedora or RedHat. My distro is Linux From Scratch.
I dunno, maybe you're using a different version of rm?
-bash-2.05b# mkdir testdir
-bash-2.05b# mkdir testdir/subdir
-bash-2.05b# touch testdir/subdir/file
-bash-2.05b# ls testdir/subdir
file
-bash-2.05b# chattr +i testdir
-bash-2.05b# rm -rf testdir
rm: cannot remove `testdir/subdir': Permission denied
-bash-2.05b# ls testdir/subdir
file
-bash-2.05b# lsattr -d testdir testdir/subdir
----i-------- testdir
------------- testdir/subdir
software upgrades are run in the background with appropriate privileges by cron, etc
And how does one get a software package into such a directory to be run by cron, etc?
PS, don't worry -- we don't hire people who log in as root here. I administer the boxes -- and I almost never need to use root.
If you can administer a box while almost never needing to use root, then I highly doubt your box is any more secure than your admin account. Administration requires admin access. Now maybe you've given such access to non-root accounts, but that seems more likely to bite you in the ass than just running as root in the first place.
Its not possible on a normally configured *nix box for a virus running as a normal user to reconfigure the OS and harm anything but that user's files
Even if this is true (it's arguable as most "normally configured" *nix boxes have root exploits), saying that a virus can't do certain things is not at all the same as saying that you can't have a virus.
arguably a big problem in and of itself
And that's the argument that I'm making.
Rootkits, the primary plague on *nix boxes depend on being able to get root on your computer to work properly (duh).
They also require the /bin directory not to be on a read-only volume, or for root to be able to remount the volume writable, which can't be said of a well-secured *nix installation.
all softwares remains in beta stages until they are abandoned. This is because bug-fixing and feature-adding are on-going processes, and are never fully completed.
I'd say once a beta has been out there for a while and there are no open bug reports remaining it's safe to call a release final. I wouldn't count feature requests, they shouldn't be responded to in the same branch once it has been declared beta anyway (some would say alpha, which is nice in theory but usually some minor features are added even after declaring an alpha release).
Anyway, let's perfect computer pilots (for both planes and cars), and it'll be a moot point.
Blow out all your engines in a plane and you'll see how moot that point is.
It is possible, as root, to load code at runtime into the kernel that is totally invisible to anyone poking at the computer.
Under linux, with kernel modules, this is possible. Even without kernel modules, it's possible to do it upon the next reboot (in Linux, under any distro I know of that doesn't run off a CD or other non-writeable filesystem).
I guess my lack of attention to this detail comes from the fact that I learned unix on FreeBSD, and in FreeBSD you can set the immutable flag on the kernel so that no one, including root, has permission to modify it. In order to remove the immutable flag, you have to be running in single user mode. It was actually just today that I came to the full realization that most Linux distros don't do this, and as far as I can tell it isn't even possible to do it on Linux.
My SOP for dealing with weirdness is to log into a console and run top as root. If I always ran as root, the spykit could be completely invisible. If I typically ran as user, then I'll see something weird.
OK, but you know what you're doing. The average Joe isn't going to. And if you've already noticed the weirdness, I would assume you're going to continue exploring further and further until you eventually find the culprit, even if that means booting from a CD and reinstalling everything.
They can't change root's LD_LIBRARY_PATH. That's the whole point of having multiple users.
It just seems to me that as you increase the number of things that you need root access to do, you also increase the ease with which an attacker can get a user to run a trojan. After all, if one needs root to install most programs, then a user isn't going to think twice when running an installer for a trojan which tells them to use sudo or su or whatever. And then, when it comes down to you and me, well we always check the MD5sum of the program before we compile and install it, whether we're root or not, right?
In my opinion, in order to properly protect an end-user from himself you need a whole paradigm shift. Firefox shouldn't run as root, but it shouldn't run as "anthony" either. Firefox should run as "firefox". And it should be installed as "firefox". Now there's something which can actually protect your data when you accidently click on a link to a website which exploits a hole in firefox. On my server system I've set up these "package users", although perhaps ironically, my only login to the system is root (it makes sense to me, because I only log in to the system to perform maintenance on it).
Yes. My /home directory is not immutable, but it wasn't touched when I ran "rm -rf /".
I wasn't arguing that it was necessary to be root in order to spy on someone. It's just that it's possible to do a better job as root.
You haven't presented anything better that you can do as root. There might be more ways to do the same thing, but that isn't any better.
Security isn't about absolutes, it's about taking precautions.
Security is about making the cost to an attacker breaking the security more than the worth derived by the attacker (although at low costs you have to remember the worth to some attackers of simply enjoying screwing up someone's system). I just don't see how running as a non-root user puts you over the top. Sure, if you run as non-root, and everyone else runs as root, then you're probably safer just because the most widespread scripts are going to be targetting others, but this just seems to me like security through obscurity.
No, they can't. Well, that's not quite what I mean. They could alias ps to /home/foo/.trojan/ps, for the low-priv user. Thing is, when Joe User calls his nerdy cousin Dwight up because his computer is slow as shit, and Dwight comes over and logs in to the console as root, typing /bin/ps aux is going to show the trojan running.
What if they changed the LD_LIBRARY_PATH?
Really, the best solution is for no one, including root, to be able to change /bin/ps. I believe BSD supports this through the immutable flag. In order to change a file marked immutable, you have to boot into single user mode.
And the local phone monopoly abusing its users did not?
There's no need to back up the entire box, because the entire box outside of the home directory can easily be downloaded.
-bash-2.05b# whoami / /
root
-bash-2.05b# rm -rf
rm: cannot remove `//lost+found': Permission denied
rm: cannot remove `//package': Permission denied
rm: cannot remove `//bin': Permission denied
rm: cannot remove `//boot': Permission denied
rm: cannot remove `//dev': Permission denied
rm: cannot remove `//etc': Permission denied
rm: cannot remove `//home': Permission denied
rm: cannot remove `//lib': Permission denied
rm: cannot remove `//mnt': Permission denied
rm: cannot remove `//proc': Permission denied
rm: cannot remove `//root': Permission denied
rm: cannot remove `//sbin': Permission denied
rm: cannot remove `//tmp': Permission denied
rm: cannot remove `//usr': Permission denied
rm: cannot remove `//var': Permission denied
rm: cannot remove `//opt': Permission denied
rm: cannot remove `//.bash_history': Permission denied
rm: cannot remove `//.journal': Permission denied
rm: cannot remove `//hdc1': Permission denied
rm: cannot remove `//initrd': Permission denied
rm: cannot remove `//rpm': Permission denied
rm: cannot remove `//www': Permission denied
rm: cannot remove `//command': Permission denied
rm: cannot remove `//service': Permission denied
rm: cannot remove `//wikipedia': Permission denied
rm: cannot remove `//hdc3': Permission denied
rm: cannot remove `//hda1': Permission denied
rm: cannot remove `//hda2': Permission denied
rm: cannot remove `//mcfly': Permission denied
rm: cannot remove `//hdb1': Permission denied
rm: cannot remove `//tools': Permission denied
-bash-2.05b# lsattr -d
----i-------- /
rm -Rf / as nonroot will make you give a sigh of relief. As root will be your nightmare.
/ /
-bash-2.05b# whoami
root
-bash-2.05b# rm -rf
rm: cannot remove `//lost+found': Permission denied
rm: cannot remove `//package': Permission denied
rm: cannot remove `//bin': Permission denied
rm: cannot remove `//boot': Permission denied
rm: cannot remove `//dev': Permission denied
rm: cannot remove `//etc': Permission denied
rm: cannot remove `//home': Permission denied
rm: cannot remove `//lib': Permission denied
rm: cannot remove `//mnt': Permission denied
rm: cannot remove `//proc': Permission denied
rm: cannot remove `//root': Permission denied
rm: cannot remove `//sbin': Permission denied
rm: cannot remove `//tmp': Permission denied
rm: cannot remove `//usr': Permission denied
rm: cannot remove `//var': Permission denied
rm: cannot remove `//opt': Permission denied
rm: cannot remove `//.journal': Permission denied
rm: cannot remove `//initrd': Permission denied
rm: cannot remove `//www': Permission denied
rm: cannot remove `//command': Permission denied
rm: cannot remove `//service': Permission denied
rm: cannot remove `//tools': Permission denied
-bash-2.05b# lsattr -d
----i-------- /
For instance, a regular user has no way to run a process without it appearing in the process list.
They could replace the program that a user uses for listing processes though.
A regular user can't load kernel modules.
You don't need to run kernel modules to spy on people.
On the other hand, root can do both those things.
Maybe, maybe not. Depends how secure your OS is.
If all of your apps are root:root r-xr-xr-x and you aren't running as root, then it's a lot harder for a virus to add itself to a system binary.
But how is that necessary? You only need to infect one executable. Or even easier, you can just infect the .bashrc.
You must not be aware of the basic function of most rootkits.
No, I'm just aware that the rootkit will change as the standard usage of the system changes. If lots of people had desktops running linux, then we'd see much different types of attacks.
The point is that with super-user access the attacker has the ability to replace _any part of the system_ with specially crafted versions the component that will hide their presence.
Well, maybe, and maybe not. I thought some unix OSes allowed you make some filesystems read-only and disallowed even root from remounting them.
This means that you can't trust the output from ANYTHING. They can easily replace things like 'who' and 'ps' so that their logins and processes don't even show up.
Right, and if I change the .bashrc to put my directory in your PATH ahead of all the others, then I can do the same thing. Or do you usually type in /bin/ps?
On a well designed system with good defaults it really isn't as easy as you might think. Certainly not impossible, or too challenging for someone who really knows what they are doing, but most attackers are script kiddies that just run stuff written by someone else.
And what is such a script kiddie going to do that can't be done without root? Hell, what is someone going to do with complete root access to my machine anyway? Steal all my bank account passwords? All they need to figure out is my gmail password and they've got access to all my bank accounts anyway. I guess they could find out something embarrassing about me which is stored somewhere on my computer and use it for some sort of extortion. But that could be done with regular old user access.
I thought about going with wireless internet. For $80/month it wouldn't be such a bad deal, since I'm already paying $65/month for DSL and a useless phone line. The problem is that my girlfriend uses the DSL, so I'd have to set up a router to the wireless connection, and it'd probably be too slow if we are both using it at once. Even then though, if I could be sure that the service had good reliability and that I could set up a router relatively easily, maybe I should go ahead and make the switch. I'd definitely take a speed hit, but that would be worth it, and I wouldn't be able to ssh in from work or other locations, but if I could get wireless internet on my PDA I wouldn't really need to ssh in from these places any more.
not to mention the fact that having to use root password to do so many things is a pain in the ass and causes users to get too used to just typing in their password without knowing what they are doing
Absolutely. I'd be fine with having a root and a non-root account on my desktop machine if the root account were basically never used. Essentially make root access needed as often as access to the bios, and make it just as hard to access. You can't do it by typing in a password, to access the root account you have to physically reboot the machine. Now that would be secure. Anything else is just a false sense of security.
you're completely failing to take into account that running in a priviliged account full time is what makes things like virusses and trojans possible in the first place
So you are claiming that it's not possible to have a virus or a trojan which runs as a non-privileged user? Sounds like you're the one who has no clue.
I can view source...The first version takes up 4 lines, the second takes up 3, and the third takes up 1, right?
The difference is that not only are you prevented from taking steps to protect your data (storing it in protected DBs or under different, secured users)
Well, I don't store that kind of data on my desktop machine in the first place. I store it on my server, which in my opinion is the only real way to protect the data in the first place. It's just to easy to get root access on a machine once you have non-root access.
but the attacker would also have a significantly easier time effectively hiding his or her presence on the system. You might not even know that your account was compromised.
I don't see how this is true. When was the last time you checked your .bashrc?
The point is that allowing them such easy root access just opens up a incredible number of possibilities for the attacker.
I never said getting root access was easy. To get root on my desktop machine you'd need physical access to it. To get root on my server, you'd need my unencrypted private key.