Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Networking Security Unix Upgrades Technology

PlanetLab Creates a More Advanced Sudo 153

Posted by timothy from the world-will-beat-a-path-to-your-door dept.
angry tapir writes "Researchers at the PlanetLab global research network have developed a potential replacement for the widely used Unix sudo tool, called Vsys, that will offer administrators far greater control over what end users can and can't access. Vsys is similar to sudo, except it offers finer-grained access to system resources. PlanetLab created Vsys as a way to allow its researchers to access low-level network functionality so they could develop new network technologies — overlay networks, user-level file systems, virtual switches — while their experimental work remained safely isolated from other users."
This discussion has been archived. No new comments can be posted.

PlanetLab Creates a More Advanced Sudo More

PlanetLab Creates a More Advanced Sudo

Comments Filter:

  • So my one question (Score:5, Funny)

    by JoshuaZ ( 1134087 ) on Monday June 20, 2011 @10:58PM (#36509022) Homepage
    Will this mean they'll need to update the xkcd shirts?

  • Better replacement (Score:1, Informative)

    by Anonymous Coward

    I'd rather use su.

  • sudo already does everything (and more!) I could possibly need it to.

    I'm certainly not against choice, just pointing out that it won't mean much for me.

    And as the AC above me has already said; 'vsys make me a sandwich' just doesn't sound right.

    • Re:I don't need more. (Score:4, Informative)

      by retchdog ( 1319261 ) on Monday June 20, 2011 @11:05PM (#36509064) Journal

      uh, yeah, that's kind of the point... vsys (ideally) won't do "more". it's not intended for users who own/admin their system.

      • It's a dumb idea today because you give the user a vm, which can be a full virtual PC or just a colinux instance.

        • Exactly... it's not like you need to buy another license to copy your OS. The only issue of course is binding a network card to that VM if they are doing any low level hardware stuff.

        • in many cases (esp. academia; this is being developed @ princeton) the point of a server is sharable resources; vm for each user would be annoying, and a vm for the researcher would be limiting.

          the use case is apparently for when you want someone to be able to do, say, limited packet analysis but not read the whole disk. i doubt it would stand up to determined assault but it might keep a sysadmin honest.

          • Re: (Score:2)

            by MikeFM ( 12491 )

            Why would a vm for the project be annoying? What whole disk? They could look at the OS files installed I guess but there would be nothing belonging to any other project or user on there. If they change something they shouldn't you can roll it back. If you want to write data but not let them read it then write it to an external log server or a write-only disk. Complex security schemes are a lot more annoying than just properly dividing security between services.

      • I already spend more effort than I like ripping out useless security features. Every project has a virtual machine, or several, and they are isolated from each other. I don't need outdated security features that just get in the way. As it is I'd be more interested in a Linux distro that came with all that crap removed. It's been years since I used groups on a production server, I never found ACLs useful, I usually disable firewalls, filesystem permissions are a hassle far more often than they are useful, et

    • Re: (Score:3, Funny)

      by cowbud ( 200323 )
      They should have called the command vudo.

  • Real users always have few terminals open as root.

    I've used sudo once in my life - and that was on someone else's crapuntu box - "sudo sh."

    Silly rabbit, sudo is for kids.

    • When you have multiple admins on a system that can be a recipe for confusion, if nothing else sudo's logging is useful. Being able to restrict your users to be able to do *some* things as root is useful, and being able to allow them to do some things as another user, not necessarily root, is powerful sometimes - I had one project years ago I had to work around an old piece of library software with an utterly arcane user privilege setup. The simplest solution ended up being creating it its own user, where ev

      • Re: (Score:2)

        by robbak ( 775424 )

        There is always suid bit, which does that in the system.

        If all your required users are in group zarkers, and the user with required permissions is zarker, then:
        -rwsr-x--- zarker:zarkers zark
        Will do that for you.

        # chown zarker:zarkers /usr/local/bin/zark
        # chmod u+rws,g+rx-w,o-rwx /usr/local/bin/zark

        • There is always suid bit, which does that in the system.

          There are a lot of things that suid won't allow you to do, like editing crontabs, changing permissions on files (you must be the owner of the file to do that), etc.

      • The one serious deficiency(still ages ahead of just handing out the root password to everybody who needs to use su) with sudo is that the restrictions are on the level of what programs the user can run, rather than what they can do.

        Given the number of *nix utilities that can be coaxed into functioning enough like a shell to invoke a full one, it is pretty easy to inadvertently assign permission for something that will let the user do anything they feel like...

    • Re: (Score:2)

      by thynk ( 653762 )

      $luser@yourbox:sudo su -
      Please enter the password for luser:
      #passwd

      Yeah, that's tough. And the first thing I do on a new Debian based box.

  • Most admins ignore sudo's granularity (Score:5, Interesting)

    by profplump ( 309017 ) <zach-slashjunk@kotlarek.com> on Monday June 20, 2011 @11:04PM (#36509060)

    Most admins ignore sudo's existing granularity, so why would they want an even more granular system? I'm not saying this new system has no uses -- clearly it does or no one would have built it -- but it's ridiculous to claim that it's likely to replace sudo in common usage when 75+% of admins have never changed the the default sudoers file, let alone wanted more even more granular control.

    • Re: (Score:2)

      by syousef ( 465911 )

      vsys -goawayauditors -noreallyf&#$off ls -l /tmp/pornstash

      just hasn't got the same ring to it as

      sudo ls -l /tmp/pornstash

    • Yea, Im not a fan of this already. You can do this here but not there. You can do that but not this over here. I got enough to deal with with the 15 passwords in my long term memory( that are going to expire in 90 days ) already.

      Stay out of my way and let me work.

      • Re:Most admins ignore sudo's granularity (Score:4, Insightful)

        by ChrisMaple ( 607946 ) on Tuesday June 21, 2011 @12:54AM (#36509488)
        If you've ever worked with someone who's productive but untrustworthy, you know that some people need to be precisely limited in their access. I know it's frustrating when I have to ask for permission just to do my job, but it's better than the guy who frequently crashes the servers to do so, or to have an unqualified person adding untested changes to a design.

        • "Working with someone who's productive but not trustworthy" is not an issue of working with bozos, either. These days, trustworthy means separation of duties - you're armoring the system in case of future bozos, and by extension, social engineering hacks.

          Example: your network design team needs a unix host running syslog NG, VSFTP, and a custom app from a vendor that needs a couple of daemons for network analysis. They're good and smart people, but they're not Unix people, they're Cisco-and-Juniper people. S

    • Re: (Score:2, Insightful)

      by Frosty Piss ( 770223 ) *

      I don't know about most *nix systems admins, but I use root.

      I'm not moron, I am neurotic about copious backups during work, I make the most of my development servers prior to pushing to the production servers, and am not generally susceptible to asking for problem solutions on-line and just assuming the rm -rf * is the solution to my problems (and it doesn't work with Windows...).

      Seriously, do most admins really use sudo? I don't believe it.

      Indeed there are a number of Linux distros that almost require i

      • Seriously, do most admins really use sudo? I don't believe it.

        Not for themselves. But it might be useful for delegating simple tasks to junior admins (with a properly set up sudoers file, or else the junior will just do as described below...)

        Indeed there are a number of Linux distros that almost require it. I don'r use them.

        You're thinking about Ubuntu, I guess? On Ubuntu, you can do sudo bash, and then it's just the same as if you had done su. And then, you can assign a password to root, with which you then can log in directly as root. No need to shun Ubuntu just because of sudo, that one is ripped out easily.

      • I use sudo on the single-user desktop/server I keep at home. Sure, sudo is configured so that user gman can do anything he wants to do if he puts the word "sudo" in front of it. But 1) it builds good habits for when I eventually work on multi-admin servers, 2) it means that when I wake up with my head on the keyboard, still slightly hung over, and find my system is completely f&$%ed, I can check the logs to see exactly what I did, and exactly what I shouldn't do next time.

    • Re: (Score:2)

      by Nursie ( 632944 )

      75% of admins probably also don't do anything much with SELinux, but some people have a use for it.

      I see this as the sudo equivalent - you can let users escalate prvileges with this, but only certain privileges. It's an extra tool for those who do need to lock things down at a very granular level, and as such will find a niche.

      The likes of you and me at home or on the average (non public-facing) server will probably not care so much.

      • It's not gonna be used on public-facing systems either. Tools like SELinux are much more appropriate for a "lock down" state with known behavior. This system was designed to grant extra privileges for unpredictable operations, which while similar in construction to SELinux is exactly the opposite application. Just about the only application for such a tool is multi-user systems where high-level privileges are needed by people other than those administrating the machine, which has to be a vanishingly small f

    • Re: (Score:2)

      by dbIII ( 701233 )
      With good defaults it may work.

    • Most admins ignore sudo's existing granularity, so why would they want an even more granular system? I'm not saying this new system has no uses -- clearly it does or no one would have built it -- but it's ridiculous to claim that it's likely to replace sudo in common usage when 75+% of admins have never changed the the default sudoers file, let alone wanted more even more granular control.

      Spoken like a true Linux at home user who has never been an administrator in an enterprise. DBA's need one level of access, developers another, application support folks another, and content providers another. This is difficult to do with sudo, where the security mechanism is to lock down users to only use specific commands. Thirty years ago in VMS I could set up print queue managers, batch job managers, email managers, etc. without having to worry about what commands they needed to use. I love the simp

    • Most admins ignore sudo's existing granularity, so why would they want an even more granular system?

      Yeah, and most people don't drive Porsche's so why would Porsche keep trying to improve their cars?

      This isn't for the people who don't want it, it's for the people who do.

  • SELinux? (Score:1)

    by Anonymous Coward

    Sounds similar to SELinux's TE and RBAC. But it would be awesome if they're easier to work with.

    • Re: (Score:2)

      by c0lo ( 1497653 )

      Sounds similar to SELinux's TE and RBAC. But it would be awesome if they're easier to work with.

      Hmmm... something tells me that there's more to it, but I'll need to try it to understand more (RBAC is about decomposing the access and defining/assigning rights to elementary resources/operations. VSys seems to come with an element of composition).

      TFA

      "In contrast to these tools and their variants, the goal of Vsys goes beyond defining ACLs [access control lists] for privileged commands. Vsys is meant to facilitate the composition of existing tools to build isolated operations," the paper states.

  • Hilarious (Score:4, Interesting)

    by timeOday ( 582209 ) on Monday June 20, 2011 @11:11PM (#36509090)
    Finer grained!

    The heaping myriad of security tools and controls is already beyond what anybody can properly utilize, by a huge margin.

  • Executable configuration? (Score:4, Insightful)

    by Max Romantschuk ( 132276 ) <max@romantschuk.fi> on Monday June 20, 2011 @11:12PM (#36509092) Homepage

    With Vsys, administrators can create scripts, called extensions, that can carefully detail which user actions are permissible. Extensions can be written in any programming language. The extensions are executable files.

    I'm sure it's flexible, but wouldn't executable configuration be a potential source of programming errors, and thus an additional attack vector? If the extension is done correctly I assume all is well, but how do you make sure it is? Or are you better off using SELinux? (Which isn't user friendly either, but at least paranoid...)

    • Re:Executable configuration? (Score:4, Insightful)

      by phantomfive ( 622387 ) on Tuesday June 21, 2011 @12:41AM (#36509450) Journal
      This solves a problem that probably exists nowhere outside PlanetLab: trying to segregate users who are trying to build experimental networks. Now, you might ask, why not just buy a different computer for each experimenter? And indeed that is what I would do, except, these experimenters are trying to experiment on clusters.

      So they are trying to segregate the capabilities of various users over many nodes in a cluster, whom they rent time to in a shared system. So there you have it. If you are trying to rent time in a shared cluster to network researchers, this is the tool for you!!

  • What? (Score:2)

    by IICV ( 652597 )

    Is it just me, or does the article just sound really confused?

    I mean, sudo has little to do with user permissions or anything like that - the mnemonic is "sub user and do". It tries to change the current user to the user specified in the command line (and uses root if none is specified), and executes the command it's given. That's it. That's all it does. It doesn't have anything to do with "fine grained permissions", that sort of thing should be handled at the OS level.

    It's not a sudo replacement, it's some

    • I mean, sudo has little to do with user permissions or anything like that - the mnemonic is "sub user and do". It tries to change the current user to the user specified in the command line (and uses root if none is specified), and executes the command it's given. That's it. That's all it does. It doesn't have anything to do with "fine grained permissions", that sort of thing should be handled at the OS level.

      No, you're the confused one. sudo does that, try man 5 sudoers in your favorite shell

  • We need to protect users from buggy install scripts that execute rm -rf /usr.

  • Imitation of Solaris? (Score:4, Informative)

    by guruevi ( 827432 ) on Monday June 20, 2011 @11:32PM (#36509196)

    Solaris (and other RBAC's) allow you to remove root and have very fine-grained controls over who does what and where even in virtual machines (containers). This problem has already been solved before many, many times so I doubt there is a need for yet another system. Even sudo itself allows for very fine grained controls.

    • Comment removed based on user account deletion

      • Yup. And you can keystroke log everything, so you can "play it back" to see who did what and when. (Meaning: you can give someone a root shell (ala sudo su -), but still log everything.)

  • Im not a huge Solaris fan. But, isn't this similar to Solaris RBAC?
  • Not trolling. Just fed up with sudo. For a single user system, why not have the option of just plain not installing it by default? I mean, its my system. I'm going to perform all root operations on it. Why do I have to be inconvenienced by this annoying application?
    • What distro are you using? Arch Linux doesn't install sudo by default. Every Arch install I've done required me to manually install sudo when it was required (and having it installed makes like a lot easier when using yaourt, so I ended up pretty much always installing it).

    • Is there something on your system that prevents you from escalating your privileges without sudo? I mean sure, minimal install set is a fine thing, but we're talking about 150k of data in /usr/sbin -- is it really a big problem for you? It seems a little like complaining that you always launch bash as bash proper and never as sh so the filesystem link annoys you and you're looking for a distro that doesn't include /bin/sh.

      Also, being able to not set -- or have to remember or change -- a root password can be

      • You provide a sound argument other than "use it because it's security" or calling me a dumbass.

        It's not really a problem as much as it's an annoyance. The file system link has nothing to do with it. My take on it is that it conditions the user in much the same way as UAC does in Windows; so the real security aspects of it are somewhat moot for a single user system.

    • Re: (Score:2)

      by Jonner ( 189691 )

      Not trolling. Just fed up with sudo. For a single user system, why not have the option of just plain not installing it by default? I mean, its my system. I'm going to perform all root operations on it. Why do I have to be inconvenienced by this annoying application?

      That is a troll. If you don't like to use sudo, then don't. It's not necessary to whine about it. I don't like ed, but you don't hear me complaining.

  • If distro's/admin's adopt it or not is another question altogether. For most, the basic tools of: "su -c 'make install'" or "sudo" do all the needed things. On a well built system, why would the (non-sysadmin) user need root access for anything? Most businesses do not allow non-IT staff to install software or change anything more than the wallpaper. You usally need to make a request to IT to have something special done on your machine anyway. It's generally a good setup that way.
    • In my electrical engineering career I frequently had to write, compile, and run programs. Although that shouldn't require root, it certainly falls into the category of installing software.

    • On a well built system, why would the (non-sysadmin) user need unrestricted root access for anything?

      FTFY. sudo allows you to specify WHAT each user is allowed to do (and even as which other user). A common use is allowing your webmaster to reload or restart apache. With sudo, you can authorize "sudo /etc/rc.d/httpd reload" but deny them from installing software, modifying iptables, etc.

      There are also some VERY creative things you can do such as setting up an internal repository (with limited applications/libraries) and allow desktop users to install extra software from it, but not add further repositories

      • Re: (Score:2)

        by h4rr4r ( 612664 )

        If your webmaster can also edit etc/rc.d/httpd or any of the config files it uses then all bets are off.

        • He may not need to. There are some web languages (python used to, but wsgi has fixed that) where modifying the site itself needs a simple "reload".

  • is wildcards in usernames. For example, i have multiple users that i have named 'test-user1', 'test-user2', etc. Now if i want to give them sudo access for a certain set of commands, i would either have to create an entry for each user in sudoers, or place them all in a group and put that in the sudoers file. Both are not quite optimal as it requires me to maintain the sudoers file manually (i want it to be dynamic) or maintain a separate group on posix level.

    What would be nice is if sudo would allow me to

    • Re: (Score:1)

      by aiht ( 1017790 )
      Should be fairly easy to make a script that converts a template sudoers-with-wildcard-usernames into a normal sudoers, with each wildcard line replaced by a set of lines for each matching user.
      Of course, that's not dynamic either, but I'm not sure what you mean by dynamic in this scenario anyway.
    • Groups should be defined in one place to avoid confusion. /etc/group is the place for that.

      You have no idea how annoying it is if you have to admin a box that has had some system admin try and reinvent the wheel and not document it thoroughly. I do consultancy for a quite a while and just finding out what people have done while a distro/OS provides proper tools for something, is a large part of dealing with emergencies while production systems are down. It may sound like a sure way to be replaced, but ple

    • Re: (Score:2)

      by Rennt ( 582550 )
      Easily done. Just make your test users members of a group called "test", then in the sudoers file grant access to "%test" instead of to individual users.

      • He wants to have group-determined-by-name behavior and not from POSIX groups. I'll agree it's "easier" in that you don't have to make/use groups, but it's a terrible conflation of functionality which makes it easy to muck up in a whole variety of ways. Just wait until "Jeremy Testarossa" creates what he thinks is a perfectly reasonable username.

        That being said, it would be trivial to setup a script that reads the list of users and builds the membership of related groups (possibly even creating groups) based

    • If you create a group (testgroup) and add that to the sodoers file, all you need to do is add your new users to that group. It requires no sudoers editing what-so-ever.

      • Re: (Score:2)

        by Errtu76 ( 776778 )

        Yes. And to others who have also said this: i did say i'm using that solution now to give permissions to users. What i meant is that wildcards for users in sudoers file would be a nice feature.

        • But it wouldn't be a nice feature *at all*. It takes away control from the admin. All a malicious user has to do is find out what things have wild cards in them, and construct a username that matches those wild cards, and trick a user who has adduser permissions to add them.

          The sudoers file must be edited with visudo, but it can be viewed with less.

          • Re: (Score:2)

            by Errtu76 ( 776778 )

            That's kind of a long shot. Tricking a user with adduser permissions usually means you trick the root user. The one who probably set up the sudoers. If he's that easily tricked, i don't need the sudoers file to do harm.

            • It's not that hard. Given your example has a hyphen (making it a "bit" harder), but lets use the following example. sudoers has "test*" listed. An new employee has a foreign name, lets call him "Timothy Estovan". The clerk given the job of creating new users (using a locked down script that only lets him pick the name) creates the user "testovan" BOOM security breach. And that's only how it can happen by ACCIDENT!
  • And here all this time I always thought sodu's more advanced replacement was su

  • ...I assume crap. Why? There are plenty systems to get finer grained rights, e.g. acl. Problem is, most developers or administrators are unable to cope with even the most simple owner/group/other access controls. Make it more flexible and powerful and you get that much more security risks that the advantages by far outweigh the problems.

  • I don't see why you cannot properly scale Sudo via LDAP: http://www.gratisoft.us/sudo/man/1.8.1/sudoers.ldap.man.html [gratisoft.us] I also believe some of the functionality described by the article can be achieved via the Plugin API introduced in Sudo 1.8.1: http://www.gratisoft.us/sudo/man/1.8.1/sudo_plugin.man.html [gratisoft.us]
  • Now somebody just needs to find the buggy buffers and write a few exploits. Nothing like the 20 year-long beta to get critical OS components to a state where sudo is now in *BSD/Linux.
  • Light (couldn't think of a better one)! It is my understanding that sudo is a setuid binary and that being true makes it one of the most dangerous code bases on a system. The more 'fine-grained' you get the more of an attack surface you expose just by the difference in code size. Sudo has already its share of vulnerabilities with the size that it is. KEEP IT SIMPLE STUPID!

  • Users vs Programs (Score:3)

    by Software Geek ( 1097883 ) on Tuesday June 21, 2011 @01:46AM (#36509658)

    The problem with the Unix security model is that it is designed to protect users against other malicious users. It does this by allowing each user to trash his own space, but not anyone else's space. But in modern computing environments, there is usually only one user, and sometimes less, and the challenge is to protect the computer against malicious programs. So, letting every program trash the one user's space isn't really that useful.
    Of course the Unix security model can be adapted to protect against malicious programs. But in practice it is so difficult that no one bothers to try.

    It appears to me, after a brief scan of TFA, that vsys just provides finer granularity without addressing the fact that the security model is fundamentally broken.

    We need a model that makes it natural and easy to run every program in its own sandbox.

    • It's easy enough to run each program in its own sandbox. It's just that those programs then aren't very useful. I'd frequently like to download files and later open them in something other than my browser. And I'd rather like to be able to print directly from my web browser, rather than downloading files, using whatever external mechanism is allowed to transfer files among the sandboxes, and then opening lpr so I can send those files to my printer.

      And as soon as you start poking holes in that system to let

      • You don't need SELinux nor Vsys, you can do that using POSIX file permission. I have a 'firefox' user which can only read write to a 'Downloads' directory, and nothing else.

        • Re: (Score:2)

          by dkf ( 304284 )

          You don't need SELinux nor Vsys, you can do that using POSIX file permission. I have a 'firefox' user which can only read write to a 'Downloads' directory, and nothing else.

          Now try scaling that up to having two real users on the same system. Or 5 users. Or 20.

    • Great idea, check it out:

      Old style, from 1982. [sessink.nl]
      Newer style, from BSD [wikipedia.org].

    • The problem with the Unix security model is that it is designed to protect users against other malicious users. It does this by allowing each user to trash his own space, but not anyone else's space. But in modern computing environments, there is usually only one user, and sometimes less, and the challenge is to protect the computer against malicious programs. So, letting every program trash the one user's space isn't really that useful.

      On Windows, yes, there is usually only one user and the main challenge is malware. But on Unix systems, no, there is no major malware problem. So you're basically saying "the problem with the Unix security model" is that it doesn't work for Windows-specific threats that are virtually non-existent on Unix systems? The main threat if you put a Unix or Linux machine on the Internet is not an infected trojan, it's hackers gaining access through unpatched vulnerabilities.

      • Re: (Score:2)

        by jedidiah ( 1196 )

        Ultimately you end up running against the age old problem. You want to protect users from themselves but they also have to be able to do things for themselves. If you restrict them too much they will just get annoyed and shut security off entirely (Vista). If it's me, chances are that I am going to want to use my own data. It's kind of hard getting around that.

  • What? You have a cheese burger now? Fine, Thank you. I am happy with my sandwich. (I see sudo wagging it's tail)

  • su (Score:1)

    by dexomn ( 147950 )

    su-su-sudIO!

  • what will be next? SCO raises from the approxmately twenty times dead and threatens to sue Linux users?

  • People hardly ever use the fine grained security in sudo anyway.

  • Sounds like RACF (Resource Access Control Facility) for mainframe operating systems (zOS and zVM). It's been around for 40+ years.

  • Subject to race conditions -- lame (Score:5, Insightful)

    by plsuh ( 129598 ) <plsuh AT goodeast DOT com> on Tuesday June 21, 2011 @05:56AM (#36510556) Homepage

    Folks,

    Does no one remember 2007? Bob Watson presented a paper on exploiting concurrency to break all kinds of things like systrace back then, complete with example code. Vsys is the same kind of thing -- it has processes executing in an outside space where you can have a race condition and force the parameters to change after the clearance check but before it actually does the work. See:

    http://www.watson.org/~robert/2007woot/ [watson.org]

    --Paul

  • Sudo works.

    More complexity breeds less security, so why do it?

    This is like upstart coming along vs. sysv. Damn, I hate managing my ubuntu laptop and my phone.

  • OK, let's see here.

    Sudo is simple, free, and ubiquitous. You can install, configure, and use it in a matter of minutes. It does what it's supposed to do, and doesn't get in the way. The need for something more powerful or fine-grained is just not there, generally speaking. If it were, then any of the other tools (RBAC, PowerBroker, etc.) would have taken hold and displaced sudo. They haven't.

    This is like extended ACLs in Unix - a solution to a problem that isn't actually a problem for most people, and has a

Slashdot Top Deals

What hath Bob wrought?

Close