Mihai's Weblog

July 17, 2009

Security issues with sudo

Filed under: Uncategorized — Mihai Varzaru @ 6:53 am

I posted the issue described bellow in a post on ubuntu forums. They closed my thread in a few hours so I am reposting it here so that you can comment on it. If I don’t get some reasonable feedback from the linux community until next week I will publish code and step by step instructions on how to use it.

1. The problem
In Ubuntu gksu and sudo can be hijacked by an attacker who already has access to the current non-administrative account. In order to do that you can simply create a bin directory in your home folder, add that directory to PATH and create in it the scripts: gksu and sudo. The scripts would silently run any application the attacker wants with root privileges and start the application you wanted to start in the first place so that you won’t notice a thing.
So, after the attacker application (got on a website with a firefox bug for example) gets access to your limited account all it has to do in order to get root access is the above and wait for you run something with administrative rights (like synaptic from the menu; at some point even the updater which runs automatically was calling gksu with a relative path). This largely defeats the purpose of having a limited account on a desktop version of Ubuntu. The code to do this is very simple and even a script kiddie can make it if he doesn’t find it somewhere on the internet.
I did test multiple times the things I said above.

2. The do it right solution
I don’t know how to fix sudo but for gksu I have an idea and I posted it on the gksu bug I submited a year and a half ago. Even if you set a description gksu should show the complete path of the application it is running. The presence of the description still leaves easy social engineering attacks (people don’t read all the text in a form or they don’t understand linux commands) but an advanced user has a chance to realize he is hacked. A more complete solution would require not being able to modify menu entries for administrative applications and, of course, having absolute paths in those menu entries.
Sudo solutions might go in the direction of modifying the most used terminal in order to treat sudo specially but I find that very problematic. The simple, working, correct solution is to also lock the screen and show what you are executing.
There might be a system wide solution for any administrative start commands in a way that the system (kernel and some base applications) treats differently the sudo/gksu type of commands. It would not use the path to search for sudo but only its predefined location and the path used for the applications sudo runs would be only changeable with root access. But I understand too little about linux as a whole in order to realize all the implications of this.
There also is the simple and very restrictive solution of not having local user paths, only paths that are modifiable by root access.
The use of unlock on some ubuntu applications (User settings) puzzles me. The password prompt you get there does not lock the screen and it seems that you don’t have a way to realize if it is the system asking you the password or an applications that looks just like “user settings” (it is very easy to create clones in open source). I haven’t looked deeper into unlock but superficially it doesn’t look like a solution for gksu problems.
Any solution without having an administrative (locked, grayed out, something that only a root application can do) screen where to enter the password and see exactly what you are running is prone to attacks where the random dialog appears and asks you for password (maybe it knows that you are running synaptic and somehow expect to be asked about password).

3. The sad solution
No gksu and sudo. Users log out and log in as root for administrative stuff. Of course they will end up using only root and here the limited account “protection” stops.

4. The “great new thing” solution
Get rid of the default limited user account on desktop installations. Even if that user account works properly in connection with doing administrative jobs its limitation don’t prevent an attacker to do damage where it mostly matters for you. For 99% of the users their documents and most other things they care about are accessible/modifiable with the limited user account. This includes those secret pictures you have with your new girlfriend. Browser settings can also be altered without administrative rights, and of course browsing history, cache and saved passwords are not locked behind the “root door”. There are things that the malware can’t do on limited accounts like sniffing, key logging, reading your credit card from firefox memory but attackers can find creative ways around these limitations (can’t they install addons without root access? don’t those addons get to the firefox internals?).  For me, the part of the system for which I need root access is the part I care less about. For instance I installed the version of Ubuntu (9.04) I am talking from 2h ago (45 min of my time I think). On my desktop system (doing usual stuff: internet, music, pictures) if an attacker gets from limited account to root access he mostly can hide better from me (rootkits). But I am not really searching for him so I won’t find him anyway.
As for limited access preventing users and applications to do stupid things. Users are not prevented too much to mess their system by root access (they need to type “sudo rm -fr /*” instead of “rm -fr /*”; saving a document in / by accident is not the biggest problem in the world; for deleting system files they could be prompted anyway). User applications are prevented to arbitrarily break the system but there is a long time since I’ve seen an application trying to break my system in any place other than the installer. Its true that default root access would allow applications to grow more ill behaved (like saving user settings in /usr) but we might find solutions for that without using a default limited account (at least not as limited as it is now; minimal set of restrictions, warnings, etc for properly behaving applications).
On Windows XP when I do not trust an application I get from the internet I do run it under a limited user account I created specifically for that purpose. That user account does not have access to my documents, my desktop, settings or anything else that matters for me. Things I save from that application go to that account documents and I copy them later from that location. People see me as an advanced user and, still, I have to admit that I don’t find the method easy to use. But if the operating system would create such a user account for me and offer me some really easy entry points to it when I might need it (like asking: do you want to run this internet application: yes, no, under limited account.) I would use it all the time. Firefox can also be run under a special limited account (you could still save files only in a predefined location), maybe each tab in its process like chrome with higher limitations if you go on some blurry web sites (enabled for private browsing?).
I have installed my Windows XP system 3 years ago, I use it a lot and I like to experiment new things but still I haven’t broken it. I did reinstall some linux systems in the mean time (it is related with understanding less linux (I did the “hard” windows experiments 12 years ago), going deeper into the system (I use sudo all the time), but mostly it is problematic updates (especially distribution upgrades)).

5. Linux security fundamentalists please read the above twice before posting :).

About these ads

35 Comments

  1. About ’1.’, which is the basis of whole post:

    Non-administrative account can’t run sudo. So, if you put sudo/gksu in $PATH and fetch user’s password, you still won’t be able to do anything. First account created in Ubuntu is *administrative* account and you should be aware of that. Whole exploit approach you mentioned works only if you use *administrative* account – just as it would work running things as root.

    Take care.

    Comment by Err — July 18, 2009 @ 5:21 pm

    • Well, that’s pretty much the point about the article, isn’t it? That the sudo-protection isn’t really enough and that the user must resort to special applications anyways?

      An if sudo doesn’t protect, maybe separating root and user-account, and not allowing su is the better way, after all?

      Comment by Ulrik — July 18, 2009 @ 5:56 pm

      • Nope. Author suggests that first user is non-administrative. That’s not true. First account created in Ubuntu is *administrator*. It’s not plain user. In multi-user environments, clueless users don’t have access to this account.

        To make a parallel with Windows – author is suggesting that exploiting browser hole, while running as Administrator account, can do harm to the system.

        sudo isn’t there for protection. It doesn’t protect, it makes things easier for sys admins.

        Notice that Ubuntu has 3 level users – root, super-user and a user. root is, well, root. super-user can get root privileges and users is just plain, simple user that can’t do anything on the system.

        Notice that OSX does the same.

        Comment by Err — July 18, 2009 @ 9:54 pm

      • A non-admin user of KPackagekit in Kubuntu 9.04 is offered a dialog which allows selection of the admin user for authentication. Typically a user would have arrived there after being notified on the taskbar of alerts being available.

        If sudo is no protection then this would mean that compromised non-admin accounts effectively also have root access where people make use of this admin authentication functionality.

        Comment by idaho — July 18, 2009 @ 11:21 pm

  2. How is this different from su? Even if you toss sudo out the window, and run on a non-administrative account. There are still times that you need to do administrative things. Are we suggesting that.

    1. You should run as a non-administrative user.
    2. When you need to do something administrative, log in as an admin user. and use sudo from that account?

    Or is su special in some way so that on a compromised account some script kiddie would not be able to detect when su is being run and would not be able to sniff out the keystrokes?

    Comment by Elder Geek — July 18, 2009 @ 5:56 pm

    • You need to enter a password for su – always.
      AFAIK for sudo you don’t need to do this under some configurations.

      Comment by flyingpenguin — July 18, 2009 @ 6:12 pm

      • You dont need a password to run su. Edit /etc/pam.d/su:
        # Uncomment this if you want wheel members to be able to
        # su without a password.
        auth sufficient pam_wheel.so trust

        Uncomment the above line and then everyone in the wheel group can do su without a password.

        Comment by Siggi — July 20, 2009 @ 1:29 am

  3. Frankly I don’t see what the problem is with opening a terminal and;

    su -
    password:

    do whatever, then Ctrl D.

    To be honest, I have never been comfortable using sudo and its ilk. I think getting root access SHOULD NOT BE easy.

    Comment by taurnil — July 18, 2009 @ 6:16 pm

  4. This issue has been solved decades ago. It is based on the assumption that there is only one environment. In Linux/UNIX, each process gets it own environment, that means, each gets its own PATH. Changing the PATH in a non-admin account will only change it for that account.

    In Windows however, there is only one environment. Changing the PATH there changes it in all processes, and therefore, all accounts. At least, this was the way it was; I haven’t checked the newer versions.

    To secure Linux:

    Delete su completely. Always use sudo and never sudo to the root account. Use sudo on each command individually.

    Never enable the root account. If you find the root account enabled, disconnect the machine from the internet, backup all data, re-install the OS from scratch, restore the data, scan it for viruses, remove all user files that are executable, reconnect the machine to the internet.

    Comment by Shawn H. Corey — July 18, 2009 @ 6:22 pm

    • But, as the post points out, sudo can be subverted to another binary (through say, a firefox-attack gaining user-level privileges of the wheel-account), modifying $PATH, and installing a script or binary roughly equivalent to:
      #!/bin/sh
      exec /usr/bin/sudo /bin/sh -c “touch /bin/should-not-be-here; $@”

      Basically (and of course that little script needs tweaking for more corner-cases), you could do whatever you want as root.

      Granted, it requires several steps, probably a re-login in between and so forth, but it actually seems this is a viable way to get root. I think I’ve got to abuse this to mess with a colleague! :D

      Comment by Ulrik — July 19, 2009 @ 1:51 am

  5. [...] Security issues with sudo « Mihai’s Weblog. [...]

    Pingback by Emmanuel Computer Consulting, L.L.C. » Blog Archive » Security issues with sudo in Ubuntu — July 18, 2009 @ 6:30 pm

  6. Please, please, please, will people stop posting this kind of garbage.

    ” The scripts would silently run any application the attacker wants with root privileges ”
    gksu / sudo are used to GET administrative privileges. If you replaced them with another script by PATH manipulation, for example in your $HOME/bin/, you can run arbitrary code, but it will have USER privileges, not root. You have to successfully run the REAL gksu / sudo program to get the root privileges. And your script cannot call the user’s desired program with root privileges so the user will notice the program he wanted did not start correctly anyway.

    This is not a security bug in sudo / gksudo or anywhere else, you can run any arbitrary code in place of any program if you manipulate $PATH – and on windows and unix and solaris and osx as well, shock horror! huge security flaws! or not.
    The point is that it will only run as the calling user, NOT AS ROOT.
    This is a key part of the Linux security model and why the second half of your article is complete nonsense. Get rid of normal user accounts for MORE security? WTF?

    The bug you filed against update-manager is completely wrong as well. I had a look at your “desktop script” and it just runs code as a normal user, not as root. I am surprised that the ubuntu devs just unquestioningly accepted your argument because it is full of holes. Oh well, the patch didn’t do any real damage.

    At most you could get the user’s password by masquerading as the gksu dialog, but that is an entirely different discussion. You do raise some valid points about locking the screen etc. to prevent stealing passwords, but this is something the kdesu / gksu devs already do think about, so you will see further improvements in the future. New technologies like PolicyKit are also coming in to further improve security by more finely dividing privileges.

    No wonder your post on the forums got closed. Stop spreading FUD with this nonsense please. And yes, I read it three times and couldn’t decide whether to laugh or cry.
    I can’t believe LinuxToday accepted this stuff.

    Sorry to be a little rude but this deserves it: ” If I don’t get some reasonable feedback from the linux community until next week I will publish code and step by step instructions on how to use it. ”
    Who the heck do you think you are to try and threaten the community? Do you think we are all idiots? Maybe you should have read the reason your thread on the forums was closed more carefully and understood why your post was nonsense rather than trying to blackmail the community. I can excuse your misunderstanding the first time but repeating it louder after being told you are wrong is just stupid.

    Comment by MasterPatricko — July 18, 2009 @ 6:34 pm

    • I assume what you say about custom binaries/scripts only having “user privileges” is related to the fact that gksu & sudo are setuid root, which the attacker’s files won’t be – but I think the point is that those files are shell scripts which are run when the user tries to run sudo/gksu (by modifying PATH), which in turn run the *real* gksu/sudo using absolute paths. The scripts modify the command the user wants sudo/gksu to execute so as to run malicious code first (with the root permissions just granted by the real gksu/sudo). The user doesn’t think anything is amiss when a password prompt comes up, because as far as they’re concerned, they just ran gksu/sudo. They also may not be aware after the fact that anything odd has happened, because the replacement commands run what the user requested after the malicious part.

      Comment by bleep — July 18, 2009 @ 9:31 pm

    • mihaiv appeared to call the first user account in Ubuntu “non-administrative” when it is in fact a member of Ubuntu’s “admin” Unix group.

      When applied to the first Ubuntu user, his points hold. I only use this account for administrative purposes and create a separate user account for day to day stuff such as internet browsing. I do this precisely for the reasons mihaiv mentions. But I bet 99% of people don’t.

      Comment by idaho — July 18, 2009 @ 10:08 pm

      • “But I bet 99% of people don’t.”

        Which is basically the thing that makes this so interesting. It almost renders the privilege-isolation as moot as in windows. :)

        Sure, this way it takes some time, requires re-logon etc. But what’s the odds of the user running synaptic-update within the first week? :)

        Comment by Ulrik — July 19, 2009 @ 1:53 am

  7. Totally agree with MasterPatricko. MihaiV is clueless about the subject.

    Comment by gigel — July 18, 2009 @ 7:09 pm

  8. “If I don’t get some reasonable feedback from the linux community until next week I will publish code and step by step instructions on how to use it.”

    Dude, is that a threat? Even given the remote possibility that your article is correct, that must be one of the most arrogant ways to address anyone, far less a community which is probably both older and far more experienced than you.

    Comment by Somebody — July 18, 2009 @ 7:18 pm

  9. Pfft, your thread got closed. I got banned for posting about a possible vulnerability. :P As others have mentioned, don’t just tease us with the concept. It does seem arrogant when you do that. Show us the proof. I did. This is just a trojan horse exploit, and not a real virus. You won’t start a horrible Linux malware spree by showing people how it works, so go right ahead. And one more thing: don’t make out like this is some sort of ultra-problem and really really bad. It really isn’t, and pretending that it is will attract flames like some of the comments above. I don’t pretend to know anything about security, and even I can tell that this problem is trivial, as is the one I described.

    Comment by bambambox — July 18, 2009 @ 8:06 pm

  10. Your idea has got to be the all-around worst idea I have heard in this year. Congrats — you take the prize of the dumbest suggestion I’ve ever heard in 2009.

    Fortunately others already solved these gksudo problems, specifically with PolicyKit. No need for suid bits in applications, no need for privileged applications, and OF COURSE no need for running as root which is what you suggested and quite possibly the WORST security idea.

    It’s good to know that you’re not in charge of distro development.

    Comment by Rudd-O — July 18, 2009 @ 8:08 pm

  11. I agree that this is not a vulnerability, but it does adress a larger issue. One option is that the linux system should be divided into three parts:
    1. user
    2. power user
    3. root

    1. user has no privledges to modify anything outside his/her home directory, and maybe even some hidden files cannot be deleted so that settings would not be lost
    2. power user. Can install applications. Thats it. So write acess to /usr, /var, and /opt. Nothing more.
    3. The person that can successfully run rm -rf /* and should be disabled. Maybe an encrypted key within a kernel update will be able to unlock administrator mode and be able to update the kernel, grub, etc.

    If i’m not mistaken, windows has a “power user” setting, but I never used it because it caused me problems.

    The second option is to use existing tools like policykit and to implement a sandbox area for installed programs from the package manager. If i’m not mistaken, a project already exists to implement this. Anyone remember what it is?

    Comment by Savage — July 18, 2009 @ 9:20 pm

  12. This idea is not nearly as dumb as it sounds on first blush, not with browser and other user program exploits out there.

    Suppose you could exploit Firefox to drop an arbitrary file anywhere, and then run it, all from malicious Javascript, Flash, Java, or other embedded language. This isn’t impossible, or even unlikely.

    This file would only be droppable somewhere the user running Firefox has permissions; like that user’s own home directory (filesystem protections in action). Also, suppose this user is the default first user (who is in sudoers).

    Given the exploit, a user visiting this site would then get the payload of a script, and the exploit would execute that script as that user. The script could create a hidden ~/.bin directory (or whatever name), and create a fake sudo executable in that directory (maybe the script is in shar format….).

    The dropper script then would mung the startup files for the installed shells (~/.profile for instance) to add the private ~/.bin to the beginning (note the default ~/.profile shipped with Kubuntu 9.04 at least does this:

    # set PATH so it includes user’s private bin if it exists
    if [ -d "$HOME/bin" ] ; then
    PATH=”$HOME/bin:$PATH”
    fi

    so you’d really only need to create the bin directory and the fake chaining sudo in it, and the user would be pwned after the next login; the default .profile does it wrong, as the private bin should always be after the system bins!).

    The fake ~/.bin/sudo file so dropped would ask the user for their password just like sudo does, scrape that password (and maybe queue it to be e-mailed somewhere, along with other machine identifiers), echo “Sorry, try again.”, then call the system sudo with the remainder of the command line (using /usr/bin/sudo $@ for bash), then after the user re-enters their password and that sudo returns, call the system sudo again with a more powerful rootkit dropper. The box is pwned. The user just thinks they fat-fingered the password, and they are oblivious to the problem.

    Once an attacker can, through some web or e-mail program, drop a script to the home directory and execute it, then the attacker can pwn that box the next time said user does the normal ‘sudo apt-get install’ that seems to be so very frequently recommended. IOW, it really is a good idea not to use a sudoer-enabled account to browse the web or do anything else that is useful, and keep the sudoer-enabled account for real admin duties.

    Not so off the wall after all, at least for command line execution of sudo.

    Hmm, I think I’m going to put a “which sudo” somewhere in PROMPT_COMMAND and watch for something other than /usr/bin/sudo to be there….

    Comment by Ubuntu-user — July 18, 2009 @ 9:34 pm

  13. Ok, test-case passed. I made a short and simple script:

    user@user:~$ cat ~/bin/sudo
    echo “Gotcha”
    /usr/bin/sudo $@
    /usr/bin/sudo echo “Now as root I own you”.

    user@user:~$

    Made it executable (chmod +x ~/bin/sudo), then did this:

    user@user:~$ sudo apt-get update
    Gotcha
    [sudo] password for user:
    Hit http://archive.canonical.com jaunty Release.gpg
    ……….
    Hit http://us.archive.ubuntu.com jaunty-backports/universe Packages
    Reading package lists… Done
    Now as root I own you.
    user@user:~$

    If a browser exploit can drop and execute (in that user’s home directory) a script to create the file (using the ever useful HERE file technique), put it in the right place, set it to executable, and set $PATH properly, it could work as sudo is currently implemented by default on Kubuntu 9.04, fully updated.

    After this is done, here’s what ‘which sudo’ tells me:
    user@user:~$ which sudo
    /home/user/bin/sudo
    user@user:~$

    The initial ‘echo Gotcha’ is just there to show that the fake sudo got called instead of the system sudo; I could include anything I would like there, or nothing for that matter; it’s the second call to the system sudo that does the main damage, although having the user password might be useful for further mischief, especially in cases where the non-password-requiring second sudo won’t work due to a change in the timestamp_timeout to 0.

    In any case, I really wouldn’t be too smug about this not being a problem.

    Comment by Ubuntu-user — July 18, 2009 @ 10:09 pm

  14. [...] es lo que afirma éste artículo en ese blog. ¿ En qué basa su argumento ?; en que se puede manipular el PATH de unas formas que [...]

    Pingback by Circo Linux – Articulos y Noticias sobre Gnu/Linux y lo que se nos ocurra. – Season 3. » Ubuntu es inseguro ?. — July 18, 2009 @ 11:09 pm

  15. Folks, STOP BEATING the dead horse. The “problems” this dude has “exposed” have been throughly addressed with PolicyKit and the fix will be shipping in the next Ubuntu version, just as it has shipped in Fedora 11.

    Comment by rudd-o@rudd-o.com — July 19, 2009 @ 12:37 am

    • Read the Title. “Security issues with sudo” (although it seems to hold for su, gksudo and friends as well).

      And, even if policykit fixes the problem, I think it’s very good that this gets a little exposure. It helps moving people over, and make people that still can’t move over (enterprise release-cycle and such) aware of the problem. I certainly wasn’t.

      Comment by Ulrik — July 19, 2009 @ 2:02 am

  16. This is all based on the assumption that the user account is compromised first. Got to get passed firewalls, AppArmor etc just to reach that point. I do agree any weakness should be fixed, and it appears that is already happening.

    Comment by GregE — July 19, 2009 @ 3:30 am

    • In Ubuntu 9.04, the AppArmor profile for Firefox is not enabled by default (e.g. see sudo apparmor_status). So the most likely vector against a desktop user would be a zero-day flaw in Firefox or maybe a malicious plugin. I don’t want root compromised because I do my internet banking in a dedicated user account.

      Comment by idaho — July 19, 2009 @ 11:39 am

  17. This is not at all related to sudo itself, or how it is configured. In nowaday’s desktop world, if you manage to get a trojan into the user’s account of an admin, you have practically owned the machine. You can do that by putting ~/bin/sudo, or you can install a daemon which ptrace()s all your processes repeatedly until you find one which has a sudo tty, or you can just bring up a dialog which looks like gksu and ask for some plausible reason for entering your password. Without a complete lockdown of the user session, trojan horses will always be possible.

    The root problems here are:

    (1) Locking down an user account to a degree which makes trojan horses impossible would reduce the usefulness of a desktop machine to practically zero these days, and nobody would accept it.

    (2) There is no technical defense against human stupidity. Trojan horses are a _social_ and _educational_ problem, not a technical one!

    Comment by martinpitt — July 19, 2009 @ 2:05 pm

  18. martin:
    I find (1) too extreme. It is harder to use if made right but that’s not even close no unusable. Think at someone who hardly does any administrative task anymore (you probably won’t find many such linux users). The people that do need to protect their root account (like mixed server-desktop computers or the bank operations example above) might accept the extra inconvenience. A proper gksu screen (and gksu the only method to get root access) with the proper information and clearly identifiable as such (no user application should be able to imitate its screen locking) would be a reasonable solution for a somewhat educated (understands how a command looks) and willing to pay attention user. The user can also be helped to understand what he is running with warnings like “non system application” (easier to identify if the ~/home/bin application is run directly, harder if it is run indirectly (like a parameter, or a setting in a given as parameter config file); you can also do it with a fixed list: synaptic, users, etc).
    Locking admin menus and making gksu special for the system (not taken from path) probably close the most common avenues of attack (common not because hackers think easier at them but because that’s how users usually get to root; some users might never use the uncommon usage patterns).
    The reasonably paying attention user described above should not be as easy to fool by the random gksu screen (he has the minimal education to realize that is unexpected and can look at what he is actually running).
    I am confident that the other methods to elevate privilege to root can be reasonable (reasonable for the users willing to accept some limitations in their special situation) solved too.
    (2) The problems I presented in the blog post involve almost no human stupidity. That is, not even a paying attention expert has a reasonable way to realize he is hacked. There is nothing in the normal flow of operations to warn him. There is no social engineering. He would have to do lots of other searches in his system to realize that something is fishy. If the computer clearly says that you are running /usr/sbin/synaptic after you clicked on it on the menu and you have no other available information to think otherwise you are not stupid if he actually runs the trojan code. That’s a technical problem, the system does not do what it clearly advertises it does (the system is not yet hacked, just the current user account; for an already hacked system this discussion is irellevant).
    Even for situations where social engineering is involved the system can help you notice easier possible problems (see my gksu example above or firefox phishing filter).

    For all the users that don’t fall in the special category above (I guess that most) I would apply point 4 of my post. The limited account does not help them and it is a frustrating inconvenience.

    Comment by Mihai Varzaru — July 19, 2009 @ 5:33 pm

  19. Thinking in browser-like terms, the possibility of substituting a local script for a system executable suggests the opportunity for password capture and forked processes, while still executing the command, as expected, in foreground.

    However, if you allow someone to copy files to your machine, you’re toast any way you slice it. Sudo and most other security measures are reasonable within their context, which virtually always assumes a degree of physical security, either through lock and key or encryption. Hand your equipment to your attacker, or vice versa, and reasonable attempts at security are compromised by unreasonable conduct, not by intrinsic flaws to the security model.

    Comment by Rambo Tribble — July 19, 2009 @ 5:53 pm

  20. I think the problem is the default configuration of Ubuntu, the unprivileged user must not be able to run all commands as root with sudo neither must be able to do this without any password.
    The problem is in the default config of /etc/sodoers file, sudo is great to delegate SOME command to SOME users such a shutdown or synaptic, is not designed to replace entirely root or su.
    Just my 2 cents.

    Comment by unix user — July 19, 2009 @ 6:58 pm

  21. I think it’s worth a mention that the way Ubuntu handles the root account (disable root, sudo from named admin account) is a better way, it’s moving the goalposts for attacks that try to bruteforce their way into root (‘root’ being the default account in Linux) by disabling root altogether, a bruteforce has to figure the username as well, making things harder.

    The real question behind sudo is how do you download/execute from the web outside social engineering? Linux makes security breaches so much harder.

    Comment by TGM — July 19, 2009 @ 11:52 pm

  22. If you really think you’re onto something here, why not be constructive for a change and file a bug here https://bugs.launchpad.net/ubuntu/+source/sudo ?

    Oh, and while you’re at it, please remember to mark it as a security vulnerability.

    Thank you!

    Comment by Muharem Hrnjadovic — July 20, 2009 @ 12:08 pm

  23. > I find (1) too extreme. It is harder to use if made right but
    > that’s not even close no unusable.

    Avoiding trojan horses will mean to disallow the user to execute _anything_ he can write to, i. e. anything from his home directory. That includes custom .desktop files, browser plugins, office documents (macros), scripts in ~/bin/, etc. This might be appropriate for some office environments, but most users would simply run away scared or disable this lockdown entirely.

    > A proper gksu screen (and gksu the only method to get root
    > access) with the proper information and clearly identifiable as
    > such (no user application should be able to imitate its screen
    > locking)

    That would require a kernel mechanism like pressing SAK (SysRq+K), which cannot be intercepted by any user program. It’s certainly not an unreasonable thing to do, but I guess there is a reason why Windows abandoned that approach again (usability). This would be pretty much the only defence against trojans pretending to be gksu, if all applications which ask you for passwords behave the same.

    However, all the fuss about protecting root is pretty much moot on a desktop machine anyway. The really interesting data lives in your home account (credit card numbers, cookies, emails, documents, etc.). That’s of course not an excuse to not protect the root user as far as possible, but nowaday’s OSes have to balance usability against lockdown. As windows firewalls and UAC, and also restrictive SELinux by default, spectacularly demonstrated, users will just turn off security mechanisms entirely if they get too much in the way.

    My personal opinion is that desktops are much better off by protecting themselves from running trojan horses in the first place, for the reasons above. I. e. nothing that you download from browsers, email clients, etc. must be executable by default, and the kernel/desktop enforce that you can only run files which are marked executable. The only exception known to me are office documents, but OO.o already warns you about embedded macros and needs you to confirm that you want to run them.

    Comment by martinpitt — July 20, 2009 @ 2:25 pm

  24. > The real question behind sudo is how do you download/execute from
    > the web outside social engineering?

    Exactly. We have already received complaints about not running downloaded .exe files by default (through wine). But I do my best to defend this behaviour. :-)

    Comment by martinpitt — July 20, 2009 @ 2:27 pm


RSS feed for comments on this post.

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: