I don't think I'll be following Ubuntu's method
|
| Author | Content |
|---|---|
| tracyanne Jul 03, 2008 3:41 AM EDT |
I'll stick to the more secure, and safer Mandriva/Redhat/SuSE/ and lots of other Linux methods with a seperate root that you su to rather sudo to. |
| cabreh Jul 03, 2008 5:53 AM EDT |
You can of course very easily set up Ubuntu the same way as Mandriva. Or you can set it up so each individual user has access only to that which they need to have access. If root has no password then no method of password attack will work on that login. If you are setting up a system as an administrator for a user you of course don't give them administrator rights and the sudo doesn't work for them. However if it is your system and you need to be the administrator it makes no never mind how you set it up as long as you don't give it autologon like some systems were want to do. |
| azerthoth Jul 03, 2008 6:46 AM EDT |
There is of course problems with that. If someone has gained access to your user password through whatever method then having a seperate root password is a must. Why? because sudo is a tattle tale. In a normal configuration there are ways to make the computer tell you if the user has sudo access. 1: 'cat /etc/sudoers' 2: 'groups' and look for wheel In the case of *buntu and a remote login, you would have to change /etc/motd so that it's not glaringly obvious that your in a system that everyone knows uses sudo only. As well as doing a custom kernel so a uname -a wont tattle as well. Barring even those doing a 'cat /etc/*-release' will tattle as well. You can see that it takes next to no time to determine if your on a sudo enabled system, and once that is determined you know which way to proceed. Heck even assuming that sudo is active but the comprimised user account does not have access, 'cat /etc/passwd' will list out the user names of other users on the system and 'groups ' will tell you which accounts do have wheel (sudo) access and you can use whatever method you want for gaining access to that account. sudo is not a security feature, sudo is a security hole and there is no method of defense that can change that fact. Multiple layers of passwords is inherently more secure than a single layer of password access. |
| rijelkentaurus Jul 03, 2008 6:50 AM EDT |
Quoting: Multiple layers of passwords is inherently more secure than a single layer of password access. Yes. As I have said elsewhere, having to guess two crappy passwords is more secure than having to guess one crappy password, so long as they are not the same (likely on a home system). If you actually have good passwords that are different, well, so much the better. |
| jdixon Jul 03, 2008 7:18 AM EDT |
> Multiple layers of passwords is inherently more secure than a single layer of password access. If you only use the account with sudo access for system maintenance and use non-sudo'ed accounts for normal system use, the Ubuntu method is as secure as having a separate root account, and is arguably more secure due to the security by obscurity feature that an attacker does not know the name of the account with sudo access in advance. Of course, that's not the way most Ubuntuites do things, so it's somewhat of a moot point. |
| Sander_Marechal Jul 03, 2008 7:26 AM EDT |
"Security by obscurity" != security. As azeroth pointed out, it takes next to nothing to determine if the system you're on uses sudo instead of root and which accounts have sudo access. Besides that, simply assuming that it's the user with ID 1000 or 1001 is correct in 99% of the cases. |
| dumper4311 Jul 03, 2008 7:38 AM EDT |
This site doesn't (as far as I can see) have a comments feature enabled. I didn't look very closely, but if anyone knows Mike Tremell's email address, it wouldn't hurt a bit to let him read the contents of this thread. He seems like a reasonable enough person, I'd be interested in what he had to say regarding the ways around *buntu's "security feature" of disabled root pointed out by azerthoth. It may talk him out of giving a pass on this false sense of security for increased convenience. |
| cabreh Jul 03, 2008 7:57 AM EDT |
I'm sorry, just how do you tell which logins are allowed to use sudo if you don't have a user login and password to begin with? Oh, and of course if remote login other than ssh is not functional? |
| jdixon Jul 03, 2008 7:58 AM EDT |
> "Security by obscurity" != security. We could argue that point ad infinitum. I'll agree that it's not reliable security by itself, but it is an added level of security. In the final analysis, all passwords are a form of security by obscurity. > ...and which accounts have sudo access. But as an outside attacker, you don't know in advance which account to attack. You have to attack blind. This IS and added link in the security chain. Not much of one, perhaps, but every link helps. |
| tuxchick Jul 03, 2008 8:11 AM EDT |
How does having a separate root plus unprivileged user account add security? Maybe I'm being dense, but both root and the Ubuntu-style sudo have the same weakness- once they're cracked, the attacker owns the whole system. Ubuntu's sudo may even add a small layer of protection because an attacker won't know what account to attack. (Which some of you already said.) Whereas root attacks roam the Internet infinitely. I don't see much of a difference either way when you're the system administrator. Unprivileged user accounts are for users you don't want messing with stuff. |
| cabreh Jul 03, 2008 8:13 AM EDT |
On an Ubuntu system there is no wheel group. A non-admin user cannot cat /etc/sudoers. They don't have permissions. So, getting the password for an actual admin user on Ubuntu would really just be the same as getting root password on something like Mandriva or Slackware. The point being, if you get admin privileges on any system that system can be hosed. But, you have to get that password first. Either the root or sudo user's password. And, the root login is far better known that what I use for a login. Maybe some of you see a difference here. I don't. |
| cabreh Jul 03, 2008 8:22 AM EDT |
Sorry tuxchick if I seem to be repeating your post. We must have been writing at the same time. |
| azerthoth Jul 03, 2008 8:28 AM EDT |
False logic, on the assumption that we have one compromised account from an outside source, all of the methods I listed for determining sudo can be done at the user level. With not a lot luck on a system where sudo is intentionally mis-configured, as in popular root password disabled systems, one is liable to find oneself in an authorized account. Barring that, it is nothing to determine if one wants to make an attack at root (su -) or at a different account that does have sudo access if the compromised one does not. With sudo active in it's popular mis-configuration it obviously increases the odds of a root level breach from a single user account breach. Quoting:But as an outside attacker, you don't know in advance which account to attack. You have to attack blind. This IS and added link in the security chain. Not much of one, perhaps, but every link helps. as stated before, run: cat /etc/sudoers (to determine if sudo is active or if the sudo group has been changed) cat /etc/passwd groups look for the wheel group Now you know which account to attack as all of this can be done from the user level. With that information you know which accounts if any you have to proceed to. As I said before, with little to no luck on a sudo active system the odds of having to proceed to any other account decrease dramatically just by the fact that sudo is active at all. |
| krisum Jul 03, 2008 8:31 AM EDT |
I guess the only difference could be when remote login is disallowed for root user (which ideally should be) and we are considering the case of remote attacker trying to get into the system after somehow cracking the password(s). So a remote attacker will need the user account password to successfully login first, and then root password to become root (which is not required for sudo case by default in *buntus). However, since azerthoth is mentioning "cat /etc/sudoers" etc. he is probably assuming that attacker already has a non-administrative account on the machine and then there would be no difference. |
| tuxchick Jul 03, 2008 8:32 AM EDT |
cabreh, great minds.... :) |
| cabreh Jul 03, 2008 8:37 AM EDT |
As I stated earlier a non-administrative account cannot cat /etc/sudoers. At least not on an Ubuntu system. |
| azerthoth Jul 03, 2008 8:39 AM EDT |
@cabreh
true ubuntu locks /etc/sudoers, however it does not lock /etc/passwd or the groups command. Instead it's even more obvious, the sudoers group in ubuntu is sudo. @TC all I am saying here is that sudo increases the chances/odds of a root level breach in its popular mis-configuration. I agree that a compromised system is a compromised system, sudo just adds a level of ease to a root level breach, especially on single user systems by an order of 100%. |
| krisum Jul 03, 2008 8:48 AM EDT |
@azerthoth: So are you saying the by looking at /etc/groups files (*buntu uses "admin" group btw), a non-administrative account can proceed to attack any of the users listed in the administrator group (instead of having to attack a single root user account in non-sudo systems) to gain root privileges? However, I do not understand how this increases the chances on a single user system where you have to break the user's password (as opposed to root's password on other systems) assuming the user would give similar strength passwords for himself or the root. |
| number6x Jul 03, 2008 8:53 AM EDT |
Quoting:"How does having a separate root plus unprivileged user account add security? Maybe I'm being dense, but both root and the Ubuntu-style sudo have the same weakness- once they're cracked, the attacker owns the whole system." In terms of security I think you are correct. I have been using an Ubuntu laptop since February and have gotten accustomed to many of Ubuntu's quirks and oddities. If you get past the initial weirdness, its not too bad in day to day use for a single user or Home Office User. However I would not recommend it for a business desktop deployment due to the single password issue. Anyone in the LXer audience that has supported corporate desktops will tell you that an appreciable part of their time is spent repairing systems hosed by the desktop user messing with files or settings that they shouldn't. With Ubuntu the desktop user has the power to screw up their own desktop using their own password. Yes, I know Ubuntu can be set up with non-privileged users. But that is extra work, and it will make your Ubuntu systems behave differently than the norm for Ubuntu. This means that many of the solutions in Forums will have to be re-worked to apply to your systems. In other words, you will have to do extra work setting up Ubuntu to avoid doing extra work, and you will also have to do extra work in re-working solutions to work on your altered Ubuntu desktops. This ends up to a net deficit. Other Linux distros follow the norm of Root user / Regular user. So the regular user's admin settings are protected out of the box. The solutions on these other distro's forums will apply directly to your supported desktops without alteration. So you get the benefit of avoiding the Windows like user self destruction and the benefit of free support from forums without modification. The Ubuntu sudo isn't bad, but I would not want thousands of desktop users in a major company to be able to screw their own systems using just their own password. My guess is that if canonical wants to do a major push into the corporate desktop, they will come out with an Ubuntu variant that will deal with this. |
| rijelkentaurus Jul 03, 2008 8:59 AM EDT |
The Ubuntu server install allows you to choose Ubuntu's approach or the tradition root-enabled style...does the advance install disc for the desktop give you that option? There is also the option in a corporate environment to setup a workstation from a server-style install, then just make an image. It should (maybe) behave like a normal Linux installation...not too familiar with Ubuntu over the past several releases to say for sure. |
| azerthoth Jul 03, 2008 9:01 AM EDT |
@krisum, from the start this has been about a compromised user level account on a system that has sudo active in its popular mis-configuration. On a single user system in this state that means root is granted automatically i.e. 100% chance of root level breach. Properly configured, sudo is a way to grant specific access to specific commands to specific users, such as mount, poweroff, etc. In it's popular mis-use it is being used as a systemic root alternative, and a less secure one. |
| tuxchick Jul 03, 2008 9:05 AM EDT |
Anyway, who needs to go to all the hassle of a remote penetration attempt, one computer at a time. Just buy a generic worker-person uniform, rent a truck, drive up and take all the computers away.
http://www.darkreading.com/document.asp?doc_id=157855&WT.svl...
Quoting: ...organizations typically are focused on online identity theft from their data resources, and don’t think about how the same data can literally walk out the door with a criminal posing as an auditor or a computer repairman. |
| cabreh Jul 03, 2008 9:08 AM EDT |
@rijelkentaurus I haven't checked on the Alternate install if that's possible or not. I have a system at work where I can test it tomorrow. Since on work based systems I always set up a separate admin login as opposed to the user having sudo rights I've never looked for that feature. I'll let you know. |
| azerthoth Jul 03, 2008 9:10 AM EDT |
TC you and I both know there are more ways than brute force to gain access to someone's password. Heck doing IRC support users perpetually offer to give passwords so that someone else can do the work for them, a form of social engineering. There are other ways too. |
| cabreh Jul 03, 2008 9:18 AM EDT |
@number6x >With Ubuntu the desktop user has the power to screw up their own desktop using their own password. Let me see, we set up an Ubuntu system where the user can sudo. The companion to that of course is we set up another distribution where the user has the root password. On Ubuntu when asked for authorization to delete the entire hard drive the user types in his/her own password. On the other system they type in the root password. And this is different how? As Jeremy Clarkson once said "It's like trying to decide who looks better, Michael Schumacher or Ralf Schumacher? Hmmm" |
| dumper4311 Jul 03, 2008 9:35 AM EDT |
@cabreh:
Here's how it's different: You give your 16 year old the keys to the beat up geo (his user account). You don't give him the keys to the lexus (the systems root account). Once he's learned how to handle himself on the road (and is paying for his own insurance and repairs and the like), then he can handle the responsibility of the better vehicle (or admin account). But so long as someone else is responsible for him, it's irrational to give him co-equal access to the vehicle (or machine). If the system's being attacked remotely, remote root login shouldn't be possible anyway (on a smartly set up system), so there's no benefit to disabling the root account locally. Attacks will come (remotely) against non-root users. On a single user system, it's almost guaranteed that this will be the sudo enabled account. Thus, azerthoth's arguments make a lot of sense. At least with a root and user account, you can try to install a bit of fear into the user related to using the root account/password. Psychologically, the "just type sudo" approach seems MUCH less harmful to a newbie - and much more convenient, which is why it's so often used/abused. Anyone who's had to spend time repeatedly cleaning up after end users can attest to this. |
| cabreh Jul 03, 2008 9:51 AM EDT |
@dumper4311 I agree completely. Therefore in Ubuntu you don't make your 16 year old the administrator of the system. My point was if you can't be bothered to make an administrator account in Ubuntu you would also be dumb enough to give the user root password on another system. Giving the same result. Everyone is talking like if you use Ubuntu you have to use sudo. You don't! Here's how easy it is to change. 1. log in as the admin user you created at install 2.. Go to System -> Administration -> Login Window 3. Click on the security tab and check allow root login (assuming you want a gui) 4. Then in a terminal run sudo passwd to create a root password 5. log out 6. log in as root and modify the user account you just used above to remove administrative privileges. 7. Now that root is activated modify ssh server (if you installed it - it's not in by default) to deny root login. There you go. |
| krisum Jul 03, 2008 10:37 AM EDT |
Quoting: from the start this has been about a compromised user level account on a system that has sudo active in its popular mis-configuration. On a single user system in this state that means root is granted automatically i.e. 100% chance of root level breach.But what makes you think that on a single user system the user will choose a stronger password for the root account than for oneself? The case you are thinking is never likely to arise in practise. Indeed because users nowadays maintain a lot of passwords (online and otherwise) many of which are for more sensitive information than that on their own PCs, it can be expected that knowledgeable users will end up using a strong password for themselves as a habit (incidentally this is the case for me that user password is stronger than the root password ). Moreover, except for on rare occasions, single user systems should not allow for remote logins and a physical breach is more likely. |
| number6x Jul 03, 2008 10:38 AM EDT |
Thanks cabreh, Your seven steps made my point much better than I did with words. |
| dumper4311 Jul 03, 2008 10:53 AM EDT |
@cabreh: Yep, you're right, it's easy to fix. But given the above, why would you want to start out with a model you'd have to change to make more resistant to damage? Note that my main concern isn't even about security, it's about the practical and effective application of a "separation of roles" model. >"My point was if you can't be bothered to make an administrator account in Ubuntu you would also be dumb enough to give the user root password on another system." Maybe, but it seems like a bad idea to me to start out as an enabler for bad practices. It's simply an issue of bad design in my opinion, and violates one of the core unix philosophies that has been so successful for the last 40 odd years. Separation of roles is only effective if the user has a clear understanding of the purpose and effect of such separation. *buntu's blurring of the line between user and admin serves the same functional outcome as microsoft's ignorance of that line on the desktop for all these years. Yes, I understand that ubuntu isn't as bad as MS in this respect, but it's the same problem, just a matter of degree. |
| dumper4311 Jul 03, 2008 10:57 AM EDT |
@krisum: >"Moreover, except for on rare occasions, single user systems should not allow for remote logins and a physical breach is more likely." It seems to me you've just demonstrated the value of having to hack two weak passwords as opposed to one. Here again, separation of roles becomes a key concept that users should understand (and in part thanks to Ubuntu and MS, they don't). Such a proper understanding would tend to lead to stronger admin passwords also, in my experience. Of course, that's as much about education as proper practice. |
| NoDough Jul 03, 2008 11:11 AM EDT |
The admin of a Gentoo system that I managed in a previous job saw outbound traffic from it that he couldn't explain. He asked me to take a looksie. One of the user's accounts had been hacked via SSH. The hacker logged in, installed, and ran a botnet node under that user's permissions. All of that user's email and documents could have also been downloaded. Root was never hacked, nor did it have to be. How did the account get hacked? The username was 'tom'. What do you suppose the new administrator changed the password to? |
| cabreh Jul 03, 2008 11:31 AM EDT |
@dumper4311 Well, I'd say Ubuntu took that root because their initial push into the market was targeted at desktop users. And it was really home, single family type users. They did the sudo thing to make it easier for the user to do things like install software and do updates on their own systems. That's why on their server installations you can set it up the "old" (normal) way. The assumption being that the server would more likely be in a business environment. In said business environment the sudo item becomes moot because nobody in their right mind would set up all the desktops so that the staff would have the sudo ability. Therefore we are back to the "problem" being the single family user. And I know that on other distributions a lot of these users would run as root because "it's such a pain to switch users to install software". So, the real problem isn't so much the sudo issue as it is the uninformed (or informed but didn't really listen) user. NoDough aptly pointed out that the problem is the user. Now in a business environment the user wouldn't have been able to use such a login and password. As the administrator I'd be enforcing proper passwords. At home users do as they please. |
| azerthoth Jul 03, 2008 12:45 PM EDT |
Now back to our regularly scheduled topic, which was not *buntu. That being that thus far no one has disproved that sudo in its popular mis-configuration is an added potential for an escalation of privileges by an unauthorized user. Lets draw a simple line Fewer distinct passwords = less secure More distinct passwords = more secure sudo == fewer distinct passwords @cabreh, your last post is the same argument MS uses. It's our users not our security model thats the issue. Apathy is a condition but should never be an excuse. |
| krisum Jul 03, 2008 12:55 PM EDT |
@azerthoth
Quoting: That being that thus far no one has disproved that sudo in its popular mis-configuration is an added potential for an escalation of privileges by an unauthorized user.I guess there would be something to disprove if something had been proved in the first place. Quoting: Lets draw a simple line Fewer distinct passwords = less secure More distinct passwords = more secureNo you misunderstand. The real security risk is potentially larger number of administrators in the default sudo configuration in *buntus. So larger number of admin passwords means greater chance of being able to break one of them. With a single admin password with or without sudo (viz. a single user system) the risks are exactly the same. |
| tracyanne Jul 03, 2008 1:15 PM EDT |
Quoting:You can of course very easily set up Ubuntu the same way as Mandriva. Or you can set it up so each individual user has access only to that which they need to have access. Yes cabreh you could (you could do great things with a basket of eggs and big stick too), You could do many many things to make Ubuntu, and it's derivatives, more secure (that is as secure as other Linuxes) but how many Ubuntu users do those things? The point of sudo to do system maintenance is to make Ubuntu much more like Microsoft Windows to use, not to improve security. I might point out that sudo doesn't actually make it easier to install software. On a Mandriva system, for example, you open drakconf (Configure Your Computer on the menu) enter the root password, when the drakconf GUI is loaded select Install and remove software, then do what you need to do. While in drakconf you can do other system maintenance as well, then kill the GUI Doing the same thing from the command line you su to root, them use urpmi packagename, and keep on doing that untill you've installed all the packages you want. then kill the console. on ubuntu you have to enter your password every time you want to load a system maintenance tool, you could end up with half a dozen different root sessions at a time, unless you are absolutely pedantic about closing GUIs when you've finished. to do it on the command line it's sudo apt-get packagename when that's finished it's sudo apt-get packagename to do the next. So it's definitely not actually easier. Remembering two passwords is not a big deal, unless you have serious memory problems, I have elderly people using Mandriva, who don't have a problem with it, and in practice I've discovered that if a person has trouble with that, they usually have trouble with even one password. Ubuntu doesn't actually make Linux easier to manage, it does make it somewhat less secure. What the universal use of sudo does do, for Ubuntu, is give the impression that it's an easier to use Linux. In other words, it's a marketing trick. |
| azerthoth Jul 03, 2008 1:22 PM EDT |
krisum, we just said the same thing. $USER logs in as $USER and wants to gain root access. $USER can use the same login password to gain access (sudo) or a seperate password (traditional root). Your point is valid in escalation of the number of distinct users with access, it simply amplifies the basic problem of a single point of failure (a single password to grant access and root access) of the user. I can see the confusion in the statement though. on a user by user basis more passwords is better, however in conjunction with multiple distinct users each as a single point of single password failure then the risk escalates accordingly. If however you remove the risk (sudo) then you have no single point of password failure (i.e. more distinct passwords, any given user must use 2 passwords to gain access vs any given user only needing a single password to truly muck the system). |
| hkwint Jul 03, 2008 1:34 PM EDT |
Quoting:to do it on the command line it's sudo apt-get when that's finished it's sudo apt-get to do the next. No, that's not the same I think. In sudo's default config it makes a 'ticket' which is valid for 15 minutes. This means you can use sudo without having to retype the root / user password for 15 minutes. You can even open one command line (xterm), use sudo, it asks for your password, then you close that xterm and get a new, and once you use sudo again it won't ask the pw because the ticket is still valid. Moreover, you can give a certain user sudo rights to install packages without using a password, while the same user has to provide a password for all other tasks. Not entirely safe of course because it assumes all packages that can be installed don't have security holes, but damn convenient. However, you claim in Ubuntu you have to retype the password for every GUI needing admin rights you open. So you see, that's not the same. Quoting:Doing the same thing from the command line you su to root, them use urpmi , and keep on doing that untill you've installed all the packages you want. then kill the console. Here, that's exactly how I use sudo - not su, and as far as I know the way it's intended to be used. I open a shell, sudo some stuff, and then close the shell. However, instead of closing the shell or 'logging out' which you would do with a su shell, you have to type 'sudo -k' to invalidate the ticket; only closing the shell is not enough (I admit: I don't do this usually). What I'm trying to say is that it's not easy to compare; there's more to it. |
| tracyanne Jul 03, 2008 1:34 PM EDT |
Quoting:And I know that on other distributions a lot of these users would run as root because "it's such a pain to switch users to install software". That would be Linspire and Freespire, since the option to login as root is not available on the Distributions I mentioned at the start of this thread, and is probably not within the skillset of someone who would login as root "because it's easier", to set up. |
| krisum Jul 03, 2008 1:36 PM EDT |
Quoting: $USER logs in as $USER and wants to gain root access. $USER can use the same login password to gain access (sudo) or a seperate password (traditional root).The default config in *buntus has the root login disabled. With sudo there is at most one password to break, that of admin user; with traditional root also there is at most one password to break [edit: that of the root]. How is the former more insecure? |
| hkwint Jul 03, 2008 1:36 PM EDT |
Forgot to mention: There are even distro's that have groups to install software. By adding your user to that group he / she can use package management without having to type a password. |
| azerthoth Jul 03, 2008 1:50 PM EDT |
The discussion, while being constantly derailed to *buntu, is not about *buntu, but mis-configured sudo. However to answer the question, the user and sudo (root) password being the same is by any definition you wish to use less secure than two seperate distinct passwords. Sudo is a single point of failure, if you get the user login you have root access, traditional root access, requires a user login and a seperate root password, multiple points must fail to gain access. Mind you we are talking about remote access, if we devolve to local access then passwords are a moot point without other methods of securing the systems. Another analogy would be a 4 wheel drive vehicle vs a 2 wheel drive vehicle. In a 2 wheel drive vehicle if you loose your drive shaft your stuck where you stop, with a 4 wheel drive vehicle you get the broken drive line off the road, put it in 4 wheel drive, and continue on your way. Single point of failure (1 password full access) vs multiple point of failure (2 passwords) |
| krisum Jul 03, 2008 2:10 PM EDT |
Quoting: However to answer the question, the user and sudo (root) password being the same is by any definition you wish to use less secure than two seperate distinct passwords. Sudo is a single point of failure, if you get the user login you have root access, traditional root access, requires a user login and a seperate root password, multiple points must fail to gain access.I do not know which traditional root access you refer to, but as far as I know root can login directly in almost all traditional UNIX systems without requiring a user to login first. If you are talking of the case where root login has been disabled in ssh, then the same can be done quite easily for an admin user when using the "mis-configured" sudo setup. |
| dumper4311 Jul 03, 2008 3:41 PM EDT |
@krisum:
>"If you are talking of the case where root login has been disabled in ssh, then the same can be done quite easily for an admin user when using the "mis-configured" sudo setup." You're (I'm starting to think intentionally) missing azerthoth's point. You've just pointed out another additional step on a distro like ubuntu (sorry az), that shouldn't be necessary in the first place, if you're properly separating user privileges (not using a mis-configured sudo). So now, instead of taking proper precautions with root in the first place, you have to take those same precautions with a wide open sudo'ed user. Seems to me you've just increased your chances of missing something by an order of magnitude. For the sake of argument, let's grant that root can log directly into your workstation (locally). You've still got to break root's password first. At the very least, you're no worse off than the sudo'ed admin user case. In the case of an intelligently passworded (and restricted) root account, you're potentially much better off. Again, it's about teaching (and enforcing) a separation of roles to new or inexperienced users that distros like ubuntu or systems like windows discount out of hand. It's dangerous and irresponsible. No, we can't make users do the right (secure) thing, but we are obligated to at least teach them the best way to operate. I think it's arrogant of such distros as you're championing to throw 40+ years of success out the window, and promote the "microsoft method" of securing your system (boy, that's worked out well, hasn't it?) for the sake of user convenience. |
| jdixon Jul 03, 2008 6:00 PM EDT |
> The username was 'tom'. What do you suppose the new administrator changed the password to? Bombadil? :) |
| krisum Jul 03, 2008 9:03 PM EDT |
@dumper4311
Quoting: You're (I'm starting to think intentionally) missing azerthoth's point. You've just pointed out another additional step on a distro like ubuntu (sorry az), that shouldn't be necessary in the first place, if you're properly separating user privileges (not using a mis-configured sudo).Talking of default configs, the distros in question do not install and enable openssh server by default. Even when one installs and enables openssh server on those, then most do permit (at least I can check for mandriva/suse) root login in the default sshd_config. So on "traditional" setups one has to do the following to achieve the configuration azerthoth has been referring to: * Install openssh server (if not installed) and enable it * Disable PermitRootLogin In "mis-configured" setups one has to: * Install openssh server and enable it * Adjust DenyGroups/AllowGroups All the above looks like an after-thought to me, because it is hard to believe that people are unaware that sshd is not enabled by default on most of the distros. Quoting: wide open sudo'ed user? Quoting: intelligently passworded (and restricted) root accountBaseless assertions. For single user systems the same user sets both the root and own password. What makes you think that latter will be weaker? Quoting: I think it's arrogant of such distros as you're championing to throw 40+ years of success out the window, and promote the "microsoft method" of securing your system (boy, that's worked out well, hasn't it?) for the sake of user convenience.Get over it. Incorrect comparisons with MS or putting me in one or other camp do not make for a stronger case. If you really want to show that "mis-configured" sudo is weaker than traditional setups then you need to show how an intruder will sweat less to gain admin privileges in the latter case [edit: assuming that passwords are equivalent in strength]. |
| azerthoth Jul 03, 2008 9:21 PM EDT |
Please, before tossing scorn on mis-configured, at the minimum read the man page for sudo, as well as the caveat at the very end warning about the very topic at hand. As to the rest, you have obstinately refused to listen to logic, even when laid out as plainly as I can manage. I have to assume that either this is intentional, or that you believe I have taken an aggressive stance against your distro of choice and have decided to defend it to the death. With the exception of a bit at the beginning where I detailed how to get *buntu or any distro to identify itself and thereby a few clues as to it's default configurations I have taken pains to not shine the light on the most popular of distros using this configuration. Either way, since the simple concept of 2 passwords good, 1 password bad, seems beyond your comprehension I see no reason to waste my time trying to enlighten you further. Please though, feel free to rail against logic and reason, someone else may feel like picking up this onerous task. |
| krisum Jul 03, 2008 11:10 PM EDT |
Quoting: Either way, since the simple concept of 2 passwords good, 1 password bad, seems beyond your comprehension I see no reason to waste my time trying to enlighten you further.Perhaps you fail to grasp that the concept is how many passwords are required to break in (which is 1 in both cases), rather than how many passwords exist. Quoting: Please, before tossing scorn on mis-configured, at the minimum read the man page for sudo, as well as the caveat at the very end warning about the very topic at hand.Maybe you should revisit that and see what it really says. |
| dumper4311 Jul 03, 2008 11:21 PM EDT |
@krisum:
>"Get over it." Take a deep breath, my friend. It's ok, I promise. :) I don't personally care how you choose to configure your machines, try not to lose your perspective. The simple fact is we have a long history of two schools of thought on security, or more specific to this discussion, separation of privilege. The Unix methodology has for 40+ years been to distinctly separate the roles of admin and user, and it's worked comparatively well. The Microsoft method has been (for most of it's history) to ignore or minimize any such distinction. They have demonstrated very effectively for us all that any such model is inherently less secure. There's nothing incorrect about this comparison - as I've stated earlier, it's the same problem, the only difference is a matter of the degree of implementation. I have no interest in putting you in either camp, as I'm not personally vested at all in what you choose, or why you may choose to do it. If you feel defensive, I'd recommend you try to objectively examine your own assumptions about the issue. :) Note: related to your challenge to "show how an attacker will sweat less to gain admin privileges", I'd present the following. As per azerthoth's advice, as taken from sudo's "Caveats" section: >"If users have sudo ALL there is nothing to prevent them from creating their own program that gives them a root shell regardless of any '!' elements in the user specification." Further, taken from a post above by hkwint: >". . . then you close that xterm and get a new, and once you use sudo again it won't ask the pw because the ticket is still valid" Specifically, if I wanted to create a linux virus, I'd probably target a distro that enables this misconfiguration by default for it's first created user (sound familliar?), and randomly test for ability to perform a harmless but restricted action. When this action completes successfully, I know that a sudo "ticket" is in place, and the virus would then compromise the system itself, removing its dependency on the otherwise uncompromised user account and password, and use your machine like a cheap . . . well, you get the idea. Considering the rabid spread of "linux for humans", this looks like a growing army of formidable spambots waiting to be harvested. Mind you, I am not a coder, and haven't tested the feasability of such an attack - it depends on a running background process' ability to abuse a later created sudo "ticket". If this isn't possible, I'd be interested in knowing, but from what I've seen so far, it sounds like a plausible threat vector. Yes, I know: "this problem is no different than for a user who runs as root for convenience". Fine, but validating one bad practice by contrasting it with another bad practice doesn't make the first method any better, it just demonstrates how incorrect both options are. Now, I'm not claiming that you'll make any such assertion, I'm just trying to help remove any possible rationalizations from the issue for anyone still reading this thread. :) |
| tracyanne Jul 03, 2008 11:59 PM EDT |
Quoting: What I'm trying to say is that it's not easy to compare; there's more to it. The point is sudo plus the user password, as used in Ubuntu, doesn't actually make it any easier to administer a Linux system, than the way you use su, or root password to load a GUI, in say Mandriva, and the single password for user and root access, as used in Ubuntu, does reduce security. Which leaves us with universal sudo, as used in Ubuntu, being a marketing ploy. "ooh look Ubuntu is the easiest Linux to use, you only need 1 password." |
| krisum Jul 04, 2008 12:23 AM EDT |
@dumper4311 This: Quoting: I have no interest in putting you in either camp,was in reference to [your quote:]"such distros as you're championing". In other words, lets stick to the issue rather than labeling others in that manner. Quoting: Specifically, if I wanted to create a linux virus, I'd probably target a distro that enables this misconfiguration by default for it's first created user (sound familliar?), and randomly test for ability to perform a harmless but restricted action. When this action completes successfully, I know that a sudo "ticket" is in place, and the virus would then compromise the system itself, removing its dependency on the otherwise uncompromised user account and password, and use your machine like a cheap . . . well, you get the idea.I see that you have shifted base. Now you are talking about a possible vulnerability in sudo's timestamping for passwords. I grant that this may be a possible line of attack. The same attack is possible when using programs like gksu that by default allow one to cache the password, so this still does not expose anything inherently insecure in the model as such. However this does not address the original discussion with azerthoth about passwords being compromised and requiring 2 passwords vs 1 password. Probably I am being very dense, but I fail to see why any of the two setups will require more than one password for root level breakage. For that matter there are other very real attacks (as in possible now) in environments where there are multiple admins managing a network of computers with traditional setup where root passwords are known to all the admins, and its not uncommon to find them working in root shells for extended periods of time. I will, however, try to avoid such digressions. |
| dumper4311 Jul 04, 2008 12:51 AM EDT |
>lets stick to the issue rather than labeling others No label, expressed or implied. you are defending a practice I disagree with, I'm simply pointing out why. You choose to call that "labeling" as if it somehow strengthens your position. I'm sorry, but I can't help you with that moderately paranoid assumption. >I see that you have shifted base. Now you are talking about a possible vulnerability in sudo's timestamping for passwords Haven't shifted a thing. Using sudo in the manner discussed is a bad idea, for a number of reasons. That is still the subject. >Probably I am being very dense Now, you said that, not me. :) I tend to agree with azerthoth, but he's already given up discussing it with you, and I'll not start. It's been discussed at length elsewhere on the internet, I'd suggest google, rather than waste more time on it. I also tend to agree with tracyanne's assessment of the use of sudo in this fashion as being a marketing ploy. "Linux for humans" looks more and more like microsoft's model of convenience over security. >The same attack is possible when using programs like gksu that by default allow one to cache the password >For that matter there are other very real attacks (as in possible now) in environments where . . . >and its not uncommon to find them working in root shells for extended periods of time >I will, however, try to avoid such digressions. Dang. I really did try to discourage such rationalization. Rather than avoid such digressions, you're relying on them. Specifically working to show that sudo's misuse really isn't so bad, compared to a series of other questionable practices. In fact, you re-worded the assertion I specifically pointed out and tried to use it as justification for a poorly configured sudo implementation. I'm afraid I must join azerthoth, reason has apparently left the building. In any case, good luck with that. Following a proven 40 odd year old set of practices myself, I won't need to rely on luck. |
| krisum Jul 04, 2008 1:20 AM EDT |
Quoting: The Unix methodology has for 40+ years been to distinctly separate the roles of admin and user, and it's worked comparatively well. The Microsoft method has been (for most of it's history) to ignore or minimize any such distinction. They have demonstrated very effectively for us all that any such model is inherently less secure.Perhaps I should clarify why this is an invalid comparison. In both cases being discussed (su vs sudo) there still is privilege separation between root user and normal user in the OS. The difference is in how they grant admin level rights to a user; su requires a distinct root password, while sudo requires the user password in its default configuration. So the real issue is one vs two passwords as azerthoth has said. Password timestamping is a possible vulnerability in sudo as is password caching in pervasive su frontends like gksu. Quoting: Haven't shifted a thing. ... Specifically working to show that sudo's misuse really isn't so bad, compared to a series of other questionable practices.The shifting was in changing from number of passwords required, to possible vulnerabilities in sudo's password timestamping. Note that many other distros use gksu for admin tasks in a similar manner, so as mentioned similar attack is possible in those. Actually gksu also allows to store in gnome-keyring which will be unlocked automatically, so that no password is ever required. Note that this is the default configuration in many distros using traditional model, and the user has to select one of "store for session" (default selection), or "store in keyring". Point being, that your example does not count towards showing any inherent weakness in 1 password vs 2 passwords. Quoting: It's been discussed at length elsewhere on the internet, I'd suggest google, rather than waste more time on it.I would have expected the answer of that to be a one or two liner. However, I will not mind if you provide me some *useful* links for the same. |
| tracyanne Jul 04, 2008 4:37 AM EDT |
The original purpose of sudo was to allow the administrator, the user with access to the root password, to temporarily allow non administrator users to perform specific, but limited, tasks, that require root access, rather than having them have access to the root password. used in that way sudo is a highly secure method of farming out system administration tasks to multiple users. Used the way Ubuntu uses it - Universal sudo to perform all system administration tasks by one or more ordinary users, based on their personal password, breaks Linux security. |
| jdixon Jul 04, 2008 5:19 AM EDT |
> Perhaps you fail to grasp that the concept is how many passwords are required to break in (which is 1 in both cases), rather than how many passwords exist. Wrong. Absolutely, totally, and completely wrong. And I agree with azerthoth that your refusal to see this is willful. Assuming a normal user configuration on almost all Linux machines (I'll ignore Linsipre/Freespire for the nonce, as almost everyone admits that running as root by default is an extremely stupid idea), the most likely means of a remote exploit is an attack against the active user account. If this attack succeeds; in the case of a single user Ubuntu system, you now have administrator access. On most other distributions, you only have access to the user account, and you still need a root exploit to gain root access. Now, as I noted earlier, this is worked around very simply by creating a second user account without sudo access, using it for your day to day activities, and reserving the sudo account for administrative purposes. This is arguably more secure than the standard Linux distro, as the attacker now has to determine which account has administrative access (as already pointed out, a comparatively trivial process, but one extra step nonetheless). Unfortunately, that's not the way Ubuntu does it. So yes, the default configuration of a single user Ubuntu machine is less secure against a remote exploit than the default configuration of most other distributions. |
| krisum Jul 04, 2008 9:50 PM EDT |
@jdixon
Quoting: Wrong. Absolutely, totally, and completely wrong. And I agree with azerthoth that your refusal to see this is willful.Look man, I have no overwhelming desire to prove my point to you. But refusing to read the previous posts and/or ignoring them is unacceptable in such discussions. Quoting: Assuming a normal user configuration on almost all Linux machines (I'll ignore Linsipre/Freespire for the nonce, as almost everyone admits that running as root by default is an extremely stupid idea), the most likely means of a remote exploit is an attack against the active user account. If this attack succeeds; in the case of a single user Ubuntu system, you now have administrator access. On most other distributions, you only have access to the user account, and you still need a root exploit to gain root access.Admin access in ubuntu is only possible if the user password is known. Or as has been discussed, the password timestamping of command-line sudo can be a risk (ideally one should use -k option or have it in .bash_logout to prevent this as has been discussed). As for 2 passwords vs 1 password, there is no reason for a remote exploiter (who is trying to crack the password) to target the user rather than root account when he/she wants to get root level access. That has already been responded to at least twice. Here: Quoting: I do not know which traditional root access you refer to, but as far as I know root can login directly in almost all traditional UNIX systems without requiring a user to login first. If you are talking of the case where root login has been disabled in ssh, then the same can be done quite easily for an admin user when using the "mis-configured" sudo setup. and clarified here: Quoting: Talking of default configs, the distros in question do not install and enable openssh server by default. Even when one installs and enables openssh server on those, then most do permit (at least I can check for mandriva/suse) root login in the default sshd_config. So on "traditional" setups one has to do the following to achieve the configuration azerthoth has been referring to: * Install openssh server (if not installed) and enable it * Disable PermitRootLogin In "mis-configured" setups one has to: * Install openssh server and enable it * Adjust DenyGroups/AllowGroups(afaik slackware also allows for root logins in default sshd config) and that a real security risk could be this (because of a greater chance of a weak password among many): Quoting: No you misunderstand. The real security risk is potentially larger number of administrators in the default sudo configuration in *buntus. So larger number of admin passwords means greater chance of being able to break one of them. With a single admin password with or without sudo (viz. a single user system) the risks are exactly the same. |
| jdixon Jul 05, 2008 7:58 AM EDT |
> there is no reason for a remote exploiter (who is trying to crack the password) to target the user rather than root account Yes, there is. it's the one that's active and using the Internet. This makes exploits via the web browser, email client, et. al., possible; which they aren't with the root account. > (afaik slackware also allows for root logins in default sshd config) Yes, it does. |
| krisum Jul 05, 2008 9:31 AM EDT |
Quoting: Yes, there is. it's the one that's active and using the Internet. This makes exploits via the web browser, email client, et. al., possible; which they aren't with the root account.In this scenario, of course, as mentioned the user password is still required to be cracked to get admin privileges (in default sudo config). So on *buntus, the exploit will still require the user password, while on others the exploit will require the root password. edit: There are two possibilities being discussed here. One is that user account is compromised without password being actually compromised -- this is the "zero" password case mentioned above. Other is that user password is compromised -- this is the 1 password case (vs 2 passwords as claimed for traditional setups). Point is that in both cases exactly one password is actually required to be known for this kind of root level exploit. |
| jdixon Jul 05, 2008 9:42 AM EDT |
> So on *buntus, the exploit will still require the user password, while on others the exploit will require the root password. Which is ONE password. On the other systems, you still have to crack two. That's the point everyone's been trying to make, and which you are deliberately ignoring. And in any case, once you have access as the user, getting the password can be as simple as calling up a shell and running passwd to change it to your password of choice. |
| krisum Jul 05, 2008 9:44 AM EDT |
Quoting: Which is ONE password. On the other systems, you still have to crack two. That's the point everyone's been trying to make, and which you are deliberately ignoring.Hmm, why would a web browser exploit on a traditional setup try to crack the user password first? Such an exploit will try to directly crack the root password. |
| jdixon Jul 05, 2008 9:49 AM EDT |
> why would a web browser exploit on a traditional setup try to crack the user password first? Such an exploit usually gives you access as the user, not as root. Our comments seem to have crossed. See my edit to my comment above. |
| krisum Jul 05, 2008 10:34 AM EDT |
Quoting: And in any case, once you have access as the user, getting the password can be as simple as calling up a shell and running passwd to change it to your password of choice.I guess you will need to think through the scenarios again. Any password changing commands require giving the old password first. Have you tried passwd command as normal user? Quoting: Such an exploit usually gives you access as the user, not as root.That's precisely the point. See my edit before. The user password is still not compromised so that is required in any case for sudo configurations. So where do 2 passwords come for a traditional system? Why would a remote exploit on traditional system try to crack the user password if root level access is desired? |
| jdixon Jul 05, 2008 12:06 PM EDT |
> Any password changing commands require giving the old password first. Actually, I believe you're correct and I'm wrong on that point. I'm not at home so I can't check. |
| krisum Jul 05, 2008 12:52 PM EDT |
Tracy,Quoting: "ooh look Ubuntu is the easiest Linux to use, you only need 1 password."For sure this is one of the reasons, though I will not speculate as to whether it is a marketing ploy or not. FYI, see this (https://help.ubuntu.com/community/RootSudo) for more reasons under the benefits section. Though the first point is useless, others are mostly accurate. Particularly useful are audit trails (though bash history can provide it to some extent), and revoking admin rights easily. I have no hesitation in criticizing *buntus where appropriate (my posts in some other forums will show that), but criticism on this account is incorrect and even after having seen huge number of arguments everywhere (probably based just on the feeling of two distinct passwords being somehow more secure magically) I have yet to see a single one that makes sense. The only one I can think of is that of a greater chance of weak password when there are multiple admins, and that can be minimized using pam-cracklib/pam-passwdqc/... |
| tracyanne Jul 05, 2008 2:43 PM EDT |
Quoting:but criticism on this account is incorrect and even after having seen huge number of arguments everywhere (probably based just on the feeling of two distinct passwords being somehow more secure magically) No a separate user and root password is not more secure magically. It is more secure technically. 40+ years of Unix, has proven that. It is a reduction in Linux security in order to make Ubuntu more attractive to Windows users, where often there is no password. That makes it a marketing ploy. |
| krisum Jul 05, 2008 2:59 PM EDT |
Quoting: No a separate user and root password is not more secure magically. It is more secure technically. 40+ years of Unix, has proven that.Well, an assertion does not make for a proof. I am not going all over this again rehashing the same things. Even though I am used to people ignoring the previous posts in most other forums, it was not expected that this will drag for so long in this forum. All that was needed to be said from my side has already been said; please see the previous posts. If there something new that you want to add, then it can certainly be discussed. |
| tracyanne Jul 05, 2008 3:45 PM EDT |
Quoting:Well, an assertion does not make for a proof. The assertion you make is utterly unproven. On the other hand the assertion I make is supported by 40 plus years of practice, and Unix/Linux good practice. BTW it's not that one did not read your previous assertions regardsing sudo, it that one sees no value in them. |
| krisum Jul 05, 2008 10:10 PM EDT |
Quoting: On the other hand the assertion I make is supported by 40 plus years of practice, and Unix/Linux good practice.For starters there are multiple flaws in your assertion. First off you provide no tangible evidence for the assertion. Secondly if you claim that traditional setup is more secure technically, then there is no reason to resort to history as evidence. Thirdly, since you claim it is "more secure" there is something that it is more than and that something is certainly not *buntus since the default setup used in *buntus has not been in existence for 40+ years. If you compare the setup in *buntus to Windows or other such systems, then that is flawed as has already been explained earlier and for the period that *buntus have been around there has not been a single exploit which is caused by this particular "weakness". |
| tracyanne Jul 06, 2008 12:23 AM EDT |
Don't you think you are getting just a little precious here? You ignore 40 years of secure usage because Ubuntu hasn't been around for 40 years. You claim I've provided no evidence that because I point to history, then you claim that the limited time Ubuntu has been around with no exploits is historical evidence that supports your assertion. Point of Fact. I have never claimed Ubuntu is like Windows. I have consistently stated that Ubuntu is less secure than a traditional Linux set up. I have further stated that I believe the single user/root password (using sudo) is a marketing ploy aimed at Windows users. No where have I claimed Ubuntu is as insecure as windows. Ubuntu hasn't been around long enough for us to know just how bad this weakness is. What we can be sure of is that separate password for super user works and works well. what we can be equally sure of is that Ubuntu is somewhat less secure than a traditional Linux system, because of the usage of a tool - sudo - that was designed to allow the system administrator to assign specific but very limited tasks, that require root access, to non administrator users, rather than giving them the root password, as a global tool for system administration. Just how less secure we can't know yet, but given that the entire system is protected by only the non root user's password, and that access to that will give the possessor the key to the kingdom, it is less secure, even if only because typically no one logs in with the root password, on a properly set up Linux system. |
| krisum Jul 06, 2008 1:18 AM EDT |
Point is that you need to provide precise scenarios and vague historical evidence won't cut it. If you claim that "I am more comfortable with traditional UNIX approach since it has been proven for ..." then I have no issues, but if you claim that "Traditional UNIX setup is more secure technically than that in *buntus" then you need to be prepared to back that statement (with a technical approach, if I may say so). |
| pat Jul 06, 2008 4:03 AM EDT |
On Ubuntu (or any other system setup in this manner), create another user via System / Administration / Users and Groups , make sure the "Administer the System" user privilege is not set. Tada, you know have a user that cannot perform admin duties via sudo, log out of your current user and log in to that one for an even more secure OS. |
| tracyanne Jul 06, 2008 4:13 AM EDT |
Quoting:Point is that you need to provide precise scenarios and vague historical evidence won't cut it. But you of course don't have to, yet it's ok for you to use the histroical argument. Quoting:and for the period that *buntus have been around there has not been a single exploit which is caused by this particular "weakness". Seems that whenever you feel the need you simply make up a set of rules that requires that everyone else justify their case in ways that you are not required to do, while you can wave your arms in the air and pronounce the Ubuntu method safe and secure. The Ubuntu method is not best practice, it never will be. The keys to the Kingdom are there for the taking, the fact that they have not yet been taken is not evidence that they can't be taken. While 40 years of best practice is known to work. |
| krisum Jul 06, 2008 4:33 AM EDT |
Quoting: But you of course don't have to, yet it's ok for you to use the histroical argument.Simply because it is your claim that traditional setup is better, so onus is on you to prove that. Anyway, this has become pointless. If you anything substantial to say, go ahead, else this is closed from my side. edit: And btw, if you read carefully that was in response to your argument i.e. to show that it did not make sense even if one were to consider it. |
| pat Jul 06, 2008 4:34 AM EDT |
One thing I haven't seen mentioned is that sudo allows better auditing than direct root access or setuid/setgid binaries. Here in the US, Sarbanes-Oxley Act (SOX) compliance is very important in the business world. |
| jdixon Jul 06, 2008 7:53 AM EDT |
> ...so onus is on you to prove that. When a traditional arrangement has demonstrated it superiority for 40 years, it's not its onus to prove anything. It's the onus of those advocating a new system to demonstrate that it's better. |
| krisum Jul 06, 2008 8:10 AM EDT |
Quoting: When a traditional arrangement has demonstrated it superiority for 40 years, it's not its onus to prove anything. It's the onus of those advocating a new system to demonstrate that it's better.Well, the discussion started with precisely the claims that *buntus model is broken and inferior, not the other way. If such be the claim then unless the side making the claim point out the flaws, there is no reason for the other side to speculate the basis of the claim. I suggest we drop this pointless line of discussion. OTOH, if there is any demonstrable insecurity in the sudo model as compared to the traditional model, then please do bring them. |
| azerthoth Jul 06, 2008 10:09 AM EDT |
Actually the discussion did not target *buntu at the start. A few people who decided to blindly defend what they perceived as a slight against *buntu just kept dragging the discussion back to it. So far you have yet to disprove in a sudo active system why a breached user account is not also a root level breach. THAT is the topic, not how or why *buntu may or may not do things. I can point to several other sudo active distros with the same issue. |
| krisum Jul 06, 2008 10:23 AM EDT |
Quoting: Actually the discussion did not target *buntu at the start. A few people who decided to blindly defend what they perceived as a slight against *buntu just kept dragging the discussion back to it.The label *buntu is being used to refer to the setup being discussed. And no, there was no "blind" defense from my side other than in your preconceived imagination. Its just that you need to pay more attention to what the other side is saying. Quoting: So far you have yet to disprove in a sudo active system why a breached user account is not also a root level breach.As has already been mentioned there are two possibilities being discussed and mixed with one another causing the confusion. Quoting: There are two possibilities being discussed here. One is that user account is compromised without password being actually compromised -- this is the "zero" password case mentioned above. Other is that user password is compromised -- this is the 1 password case (vs 2 passwords as claimed for traditional setups). Point is that in both cases exactly one password is actually required to be known for this kind of root level exploit.It is not clear which breach you refer to. I assumed it to be the second one. In either case the attacker needs exactly one password (user password on sudo'ed systems vs root password). So, no a breached user account does not necessarily mean a root level breach unless the user password is compromised. If user password breach is being considered then as already pointed out umpteen number of times, an attacker will directly go for the root password on traditional setups if root level access be desired. So your starting point of user password breach on both systems is a flawed one. |
| azerthoth Jul 06, 2008 10:38 AM EDT |
Default configuration for most systems is to not allow remote root access, which means you must breach a user account first. As I pointed out at the start, you can get the system to readily identify itself and have it give you all needed information as to which direction you need to proceed next. Odds are better than even, if you find yourself on a sudo active system, you need to proceed no further, as you already have what you want, no further hammering on passwords needed. Versus a traditional Unix, where you would still need to access one more password. |
| krisum Jul 06, 2008 10:51 AM EDT |
Quoting: Default configuration for most systems is to not allow remote root access, which means you must breach a user account first.No in most linux distros, the default sshd configuration allows for root logins (Mandriva/Suse/Fedora/slackware). Which system are you talking about? |
| jdixon Jul 06, 2008 11:17 AM EDT |
> ...in most linux distros, the default sshd configuration allows for root logins (Mandriva/Suse/Fedora/slackware). Slackware assumes you're the administrator and know what you're doing (I know, it's a novel concept); so if you want root access via sshd disabled, you'll disable it. I have two firewalls and tcp/ip wrappers setting between me and the Internet. I'm not too worried about allowing root to login via sshd from our lan addresses. |
| krisum Jul 06, 2008 11:30 AM EDT |
Indeed, the default in sshd is to allow for root logins (check the manpage of sshd_config for PermitRootLogin), so it is allowed unless the distro explicitly disables it. If this is the only security concern we are talking about then disabling it in both the setups is equally simple (PermitRootLogin no, vs, DenyGroups admin). |
| eggi Jul 16, 2008 11:22 AM EDT |
Guys, Thanks for your comments - I always thought I had this board set up to auto-notify me if a thread was started, but I'm realizing that's not the case. BTW, I don't allow comments on my blog, but do include my email address (eggi@comcast.net) in every script (Perhaps I should put it near the top of the page in a static element box to make it easier for folks to get in touch with me). I'm definitely interested in all feedback, as it can only make the site better. Unfortunately, even if I moderate comments, Google crawls me every day and has sent me warning about adult posts (waiting in moderation no less) on my site and I don't want them to shut me down. They are big dogs and may just be blowing steam, but I don't want to push it. As for my own personal politics, I've been an admin for almost 13 years and was taught the trade in a company where they used rsh with a .rhosts pass for root (The complete opposite of security, in many ways other than that specific example), but it was a great place to learn, and then to learn again why I was doing everything incorrectly :P I believe in either a very strongly encrypted (and/or convoluted) root password and no direct access. In my post, I was attempting to "clear the air" on some other posts I'd read about actually "removing the root user" entirely as a security measure (which would be a tricky proposition and probably not for most folks). I like sudo, but personally stick with using straight-up "su" with 4750 perms and having all the admin's who require root access to be in the only group that has access to even run su, and then also know the root password. I've toyed with s/key systems, for root password, as well, but found them to be hazardous (At least to my sleep ;), but (perhaps due to my writing style, which is a bit lengthy and effusive) I gave the wrong impression that I fully support the NoPassword sudo-only access to root method. I am still strongly in the "root should have a password and only a few people should know and only those people should be able to use su at all, if possible" camp. Thanks, again, for all the feedback. You can email me direct anytime. I usually can't gaurantee a response more than once in a 24 hour period, but I can always be reached there. I'll be checking back here more often from now on. Nice to know someone's actually reading my blog ;) Best wishes, Mike |
| Sander_Marechal Jul 16, 2008 2:19 PM EDT |
eggi, can you please break up the long root-should-have-a-password-and-only-a-few-people-should-know.... line? It makes all the comments in this thread expand to the right, under the menu. This makes them unreadable even on my 1280 wide screen. |
| eggi Jul 16, 2008 5:16 PM EDT |
All set :) Sorry about that. I'll keep that in mind for future responses. Thanks for the heads up! , Mike |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!