PlanetLab Creates a More Advanced Sudo

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."

Comments

So my one question

[JoshuaZ]

Will this mean they'll need to update the xkcd shirts?

Re:So my one question

[SeaFox]

"Vsys make me a ham and swiss on rye... with dijon, lettuce and tomato. Hold the onion."

Re:So my one question

[evanism]

Sudo, make me a sandwich.

Now: FFFFUUUUUUUUU, make me a sandwich.

Re:So my one question

[delt0r]

Sudo, make me a sandwich.

You are not a valid user in the sudoers. This incident will be reported.

Test it...

[Anonymous Coward]

Vsys sudo rm -rf /

Re:Test it...

[Hylandr]

# :vsys su -

Password for User : FU

$ :

- Dan.

Re:Test it...

[nschubach]

Why did putting ':' on your bash shell output '- Dan'? Seems like an odd alias. ;)

Better replacement

[Anonymous Coward]

I'd rather use su.

Re:Better replacement

[Anonymous Coward]

you dunce

Re:Better replacement

[buchner.johannes]

Isn't PolicyKit meant to do the fine-control root access?

Re:Better replacement

[Anonymous Coward]

What idiot marked this as "Informative"?

I don't need more.

[drunkennewfiemidget]

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.

[retchdog]

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.

Re:I don't need more.

[cowbud]

They should have called the command vudo.

Re:I don't need more.

[tqk]

They should have called the command voodoo.

FTFY.

I've never seen the point of sudo. "su -c $blah" should be all anyone needs.

Re:I don't need more.

[SigmundFloyd]

I've never seen the point of sudo. "su -c $blah" should be all anyone needs.

You are missing the whole point of sudo...

Sudo is for letting unprivileged users issue specific administration commands without knowing or entering the root password. Yes, it can also be used as a temporary `su`, but that's not what it's for.

I just hope this new tool comes with better documentation, because I always hated that unsightly sudoers(5) man page with a passion.

Re:I don't need more.

[tqk]

You are missing the whole point of sudo...

Sudo is for letting unprivileged users issue specific administration commands without knowing or entering the root password.

I know what sudo does. That doesn't mean I like it. sudo is "for letting unprivileged users" ignore the existence of root, plain and simple. Bad idea.

Re:I don't need more.

[SigmundFloyd]

I know what sudo does.

If you knew what sudo does, you wouldn't have written this:

"su -c $blah" should be all anyone needs.

Re:I don't need more.

[drinkypoo]

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.

Re:I don't need more.

[nschubach]

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.

Re:I don't need more.

[nabsltd]

I know what sudo does. That doesn't mean I like it. sudo is "for letting unprivileged users" ignore the existence of root, plain and simple.

I don't think you really do know what sudo is there for. The most popular use for it where I work is to allow users to run commands as someone other than themselves, but not root. Although you can do some of this using group permissions on files, you can't do things like edit crontab entries without a tool like sudo.

Re:I don't need more.

[retchdog]

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:I don't need more.

[MikeFM]

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.

sudo? why bother

[tomhudson]

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.

Re:sudo? why bother

[Anubis350]

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 everyone who needed the software ran it as that user (transparently by opening it using a shell script I wrote). sudo is a very useful tool :-)

Re:sudo? why bother

[Anonymous Coward]

You pretentious and ignorant fuck pig. You can enable su on Ubuntu too.

Re:sudo? why bother

[Anonymous Coward]

People who aren't idiots use sudo for proper logging. You're forgiven though; we were all imbeciles at some point.

Re:sudo? why bother

[thynk]

$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.

Re:sudo? why bother

[Anonymous Coward]

Unless you know the possibilities that are already there. Kerberos, MAC and multilabel. Even more options available and the MAC framework is extensible.

Re:sudo? why bother

[robbak]

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

Re:sudo? why bother

[Anonymous Coward]

You don't need to do that in Debian though.

Re:sudo? why bother

[bcmm]

I hate to break it to you, but you're an Ubuntu user, not a Debian user.

Re:sudo? why bother

[tqk]

People who aren't idiots ...

... Only give root privs to those who know how to use them.

*buntu has other ideas/agenda, which may be either good or bad, dependent upon circumstances.

Re:sudo? why bother

[fuzzyfuzzyfungus]

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:sudo? why bother

[thynk]

See, even I can learn something new every day.

Re:sudo? why bother

[nschubach]

... only add someone to sudoers who know how to use it.

How is that any different?

Re:sudo? why bother

[goarilla]

Sudo does have some rudimentary shell-escape functionality.

Re:sudo? why bother

[nabsltd]

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.

Most admins ignore sudo's granularity

[profplump]

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:Most admins ignore sudo's granularity

[syousef]

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

just hasn't got the same ring to it as

sudo ls -l /tmp/pornstash

Re:Most admins ignore sudo's granularity

[Roachie]

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

[Anonymous Coward]

well I don't know about most admins but I use sudo at work, and at home. In fact every one uses it in the fortune 500 company I work at. Its used by developers, admins and the ops. So I guess were in the 25% eh? good to be a cut above the rest i suppose!

Re:Most admins ignore sudo's granularity

[Frosty Piss]

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 it. I don'r use them.

Re:Most admins ignore sudo's granularity

[ChrisMaple]

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.

Re:Most admins ignore sudo's granularity

[Nursie]

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.

Re:Most admins ignore sudo's granularity

[profplump]

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 fraction of UNIX-like systems. And even on such systems the admin will still use sudo to to their own work.

Re:Most admins ignore sudo's granularity

[ArsenneLupin]

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.

Re:Most admins ignore sudo's granularity

[dbIII]

With good defaults it may work.

Re:Most admins ignore sudo's granularity

[SoupIsGood Food]

"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. So they come to you to run their Unix host, because you know how to rig up a virtual host, but they don't necessarily want or need you every time they reconfig their syslog config or the app needs to be kicked over because it froze.

On the other hand, they sure as hell don't want to be responsible for opening up a security hole or taking down the system. They don't have time to be Unix admins, and you don't have time to be an application support engineer.

This is where sudo and now Vsys comes in. It lets them screw with their mission-specific configs and processes without the risk of knocking over the box. This makes everyone happy.

Re:Most admins ignore sudo's granularity

[gman003]

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:Most admins ignore sudo's granularity

[Anonymous Coward]

From TFA:
"Although it probably wouldn't replace sudo for the casual user, Vsys would be more appropriate for data center administrators"

It also points out the extensibility of the tool using scripts in any programming language. So, I think you are right, 75% of admins would not want to use vsys, but it sounds like a valuable tool for large installations.

Re:Most admins ignore sudo's granularity

[Princeofcups]

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 simplicity of unix, and root/sudo should always be the default system control. But for machines with multiple users and teams, anything that helps manage security at a higher level would be quite welcome.

Re:Most admins ignore sudo's granularity

[BeanThere]

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.

Re:Most admins ignore sudo's granularity

[Anonymous Coward]

I wouldn't say we ignore it, so much as we don't really need it, more often than not. sudo is useful for accounting and multiple admins, but in environments where this is the case there is rarely much need to restrict access to such a level: either the person an do the work, or they can't. More often than not, it's one or two guys maintaining a large number of servers. It's not like in Windows where every user needs to be granted heightened ACLs to do basic/different things. A normal account is already pretty flexible.

Re:Most admins ignore sudo's granularity

[Anonymous Coward]

Indeed I never change the sudoers file, because op is distinctly better than sudo -- and doesn't sound like a superlatively-annoying Phil Collins song.

Re:Most admins ignore sudo's granularity

[Roachie]

We have all borked boxen -that's what the tapes and snapshots are for.

Now, access is and should be very limited to production systems. But for development and test the thought of keeping track of all my privileges here and there fills me with ennui.

"In dev, Sudo will do!"

SELinux?

[Anonymous Coward]

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

Re:SELinux?

[c0lo]

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

[timeOday]

Finer grained!

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

Re:Hilarious

[Anonymous Coward]

Well, some people are more discriminating when it comes to their sandwiches.

Re:Hilarious

[gwstuff]

True. OTOH, systems research is as much about redoing as inventing. If canonical utility was the only criterion then Linus would not have reinvented Unix, Google would not have reinvented Firefox, (...). Read the "Related work" section of the linked paper - it talks about a ton of such works.

Executable configuration?

[Max Romantschuk]

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?

[phantomfive]

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!!

Re:Executable configuration?

[Anonymous Coward]

It seems like it could be useful for leasing out time on your pet botnet without risking it being stolen from under you.

Y'know, assuming your botnet is made of *n*x (probably ubuntu) boxen, instead of Windows PCs.

Re:Executable configuration?

[phantomfive]

lol ya, and as a bonus, you can rent time to the owner! Brilliant idea.

What?

[IICV]

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 something that changes the OS security model and probably has some other junk. Even with this thing installed, sudo will still sub user and do.

Re:What?

[OverlordQ]

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

Re:What?

[Anonymous Coward]

if the sudoers file is at default settings and user is allowed to sudo, all bets are off, right?

I prefer system that sudo doesn't exist (silly me, but listen ...)

If the user is also sudoer (as default settings), then sudo su - makes me a root (regardless root being disabled, OS X, I'm looking at you *argh*)

so, in a system where sudo is not 'enabled (single user case), I feel better having 2 separate passwords, root and user, instead of owning the system by sudo... ... maybe I'm just misinformed...

Re:What?

[Anonymous Coward]

I mean, sudo has little to do with user permissions or anything like that - the mnemonic is "sub user and do".

It's "super user do", actually.

Re:What?

[malsbert]

that would be "switch user and do".

that is; you do not have to switch to root any user will do :)

try; man 8 sudo

Re:What?

[icebraining]

You do realize that you don't need to use the default settings, right? I have a sudo entry for a daemon which only lets it run one specific command. I also have a sudo entry that lets me run Firefox as another user, to avoid having an exploit screw with my $HOME.

Just because you don't like the default settings doesn't mean the tool isn't useful.

Re:What?

[Anonymous Coward]

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

You must be one of the 75% of sys admins that have the default sudoers file that profplump mentioned.

A very real use case scenario

[simoncpu was here]

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

Re:A very real use case scenario

[Anonymous Coward]

Just don't install bumblebee in the first place.

Imitation of Solaris?

[guruevi]

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.

Re:Imitation of Solaris?

[toejam13]

Or of PowerBroker. We use it on our SunOS and Linux boxes at work, and it offers both fine grained delegation of rights as well as advanced logging.

Re:Imitation of Solaris?

[psyclone]

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.)

Solaris RBAC

[prudhvi]

Im not a huge Solaris fan. But, isn't this similar to Solaris RBAC?

Single user system

[thatskinnyguy]

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?

Re:Single user system

[wikid_one]

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).

Re:Single user system

[XFire35]

Yaourt... *shudder*

Re:Single user system

[profplump]

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 useful even on single-user systems. As can the ability to run specific programs with root privileges without authentication/etc., perhaps even limiting the arguments given to those programs to help keep their usage safe.

Re:Single user system

[Noughmad]

What's wrong with Yaourt, and do you know a better option?

Re:Single user system

[Anonymous Coward]

"Why do I have to be inconvenienced by this annoying application?"

It's called security, dumbass. And you have a duty to keep your computer secure if it's connected to other computers.

Re:Single user system

[thatskinnyguy]

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:Single user system

[GofG]

Yes. Clyde does exactly what yaourt does, except much faster and better. There are also many other options, but Clyde is the best.

Re:Single user system

[Jonner]

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.

Why do users need root?

[IronSight]

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.

Re:Why do users need root?

[ChrisMaple]

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.

Re:Why do users need root?

[DarwinSurvivor]

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. This would allow your desktop users to pick their web browser, text editor (vim, emacs, geany, eclipse, etc) without allowing them to install a web server or something that needs proper securing.

Re:Why do users need root?

[Anonymous Coward]

It all depends on what you mean by "installing". In your case, simply putting them into your home directory is enough, and that certainly doesn't require any additional privileges.

Re:Why do users need root?

[h4rr4r]

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

Re:Why do users need root?

[DarwinSurvivor]

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".

what sudo can't do

[Errtu76]

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 create a test-* entry. Maybe vsys can do that. Although that's the only missing feature of sudo i would actually need. For the rest, sudo suits my needs just fine.

Re:what sudo can't do

[aiht]

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.

Re:what sudo can't do

[Anonymous Coward]

Just use groups to handle it. I believe usermod handles wildcards.

Re:what sudo can't do

[Rennt]

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.

Re:what sudo can't do

[DarwinSurvivor]

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:what sudo can't do

[Errtu76]

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.

Re:what sudo can't do

[profplump]

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 on the username-embedded group names.

Re:what sudo can't do

[zippthorne]

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:what sudo can't do

[Errtu76]

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.

Re:what sudo can't do

[DarwinSurvivor]

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!

Re:what sudo can't do

[Anonymous Coward]

I don't see how adding a user called "JezT" would cause any problems for him.

Really?

[TheRealQuestor]

And here all this time I always thought sodu's more advanced replacement was su

Re:Really?

[Anonymous Coward]

Do you really not know what benefits sudo offers over su? It's main benefit is that it allows you to give permission to run only selected commands to specified users or groups, with su it is all or nothing, sudo really is better than su. Although for a single user system you probably won't need this extra control, but there are still uses even for a single user system unless you always run as root.

Without reading the article...

[Tanuki64]

...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.

Re:Without reading the article...

[Anonymous Coward]

it actually sounds like they would've benefitted more from virtualboxes.

Sudo + LDAP + Plugins

[tanawts]

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 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

kerndo appdo drvdo rootdo

[Anonymous Coward]

One "admin" password for everything is possibly not enough,

What I want is a separate password for the various layers of the System.
e.g
1 to do things to the kernel and above,
2 to stop/start/load/unload/configure driver modules or do operations on drivers
3 to install/remove apps
4 user security for the rest.

So I don't have to give the admin/root password to install an app I just downloaded, or load a potentially flaky new driver

To sum up our responses to this...

[fahrbot-bot]

...yawn.

you've answered yourself

[dutchwhizzman]

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 please think of the poor sod replacing you when you've moved on to greener pastures. Either use the tools the way they were intended, or document everything you're doing like you're passing on to a novice.

Testing

[dimethylxanthine]

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.

I like my sudo like I like my salad...

[pasv]

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

[Software Geek]

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.

Re:Users vs Programs

[Anonymous Coward]

That's exactly what selinux does. Of course when every action each program can take needs to be permitted, you end up with a large complex configuration, or you can't even boot the machine. Fortunately modern distributions normally come with selinux configs for the system and the most common applications.

Re:Users vs Programs

[profplump]

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 programs share disk space or talk to each other via IPC or sockets or whatnot you're in the same mess we have now -- all you really have is disk privileges and memory isolation to keep you safe. Systems like Apple's iOS provide pretty good sandboxing, but they do so at the cost of a lot of functionality that I'm not willing to give up. And even that leaves plenty of potentially exploitable holes.

Now, there are approaches (and this new system actually works along those lines, as does SELinux) that allow you to say things like "user A can write to ~/Downloads and ~/bin from their shell, but user A running program X can only write to ~/Downloads". That's not complete sandboxing, but does provide fine-grained controls to mitigate potential damage. Unfortunately it requires a very detailed profile of what is "normal" behavior for a specific user/program combination, and while that may be worthwhile on an Internet-facing server with no local users it would sure make it hard to do normal work on your self-administered desktop unless you were willing to continuously manage the behavior profiles.

Re:Users vs Programs

[icebraining]

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:Users vs Programs

[dkf]

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.

Re:Users vs Programs

[phantomfive]

Great idea, check it out:

Old style, from 1982.
Newer style, from BSD.

Re:Users vs Programs

[BeanThere]

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:Users vs Programs

[jedidiah]

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.

Re:Users vs Programs

[Anonymous Coward]

Here's one solution:

Make a 'jail' user and add your user to the 'jail' group.
Set the 'jail' user's umask to 002 (put "umask 002" in jail's .profile); this will ensure that any file that 'jail' creates will be group-writable

Make your shared directory group-owned by the 'jail' group:
chown -R youruser.jail /home/shared

Make the shared directory setgid (so that new files in that directory will inherit the group ownership):
find /home/shared -type d -exec chmod g+s '{}' \;

Now both 'youruser' and 'jail' will have write access to any files in /home/shared, including any files that are created by 'jail' (but not files that are created by 'youruser').

It's not perfect, but it's still somewhat powerful. You can even do partial per-directory umasks by overloading the 'cd' command, but this is far from perfect:
    http://forums.gentoo.org/viewtopic-t-873433.html

For finer control, there's no way around it -- you need ACLs

Re:Users vs Programs

[goarilla]

Not only that now he has to maintain his own version of firefox or force his package manager to
honour its permissions.

Noooo Was: Re:Executable configuration?

[Anonymous Coward]

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!!

You don't do that. Building experimental networks should be confined to virtual interfaces as long as possible. Just like giving kernel module writers access to a live and shared system. There is no problem handing over virtual networks to other people. There are so many proven methods we really don't need a new program. I think many people should learn what is already possible for years before writing new stuff. Would also help finding regressions in the linux userland. People shouldn't think they are the only ones with a certain problem. They should look how people did it before.

cheese burger?

[Phoe6]

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

su

[dexomn]

su-su-sudIO!

I still log in as root

[Anonymous Coward]

Does that make me a bad person?

Oh, it's this time of year again...

[Pf0tzenpfritz]

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

Fine grained?

[MichaelSmith]

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

There's no story here...move along.

[jacobsm]

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

[plsuh]

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/

--Paul

Re:Subject to race conditions -- lame

[Anonymous Coward]

Folks,

Does no one remember 2007?

I remember 2007 I think, just not the bit when Bob Watson presented a paper on exploiting concurrency.

Containers LXC

[Anonymous Coward]

Just create LXC + CGroups....

More protection?

[Anonymous Coward]

Does it mean that new tool will save me from doing 'sudo rm / -rf' ??

Re:More protection?

[JonJ]

I don't know, but you should get a smack in the head for entering the command line switches last.

Why?

[SCHecklerX]

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.

Really not necessary

[swordgeek]

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 already been solved.

Link to the package

[gwstuff]

In case other people had as much trouble as I did finding the package: www.cs.princeton.edu/~sapanb/vsys [Download Vsys] http://git.planet-lab.org/?p=vsys.git;a=summary [git repository] ...also, interestingly, Vsys is not written in C, but Ocaml, which is a solid type-safe programming language. This is reassuring from the security standpoint given that it is a recent package.

Security from a past life..

[MikeFM]

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, etc. Heck, the only time a real person logs into most of my systems is when something goes wrong with permissions or some other protection feature and causes a problem.

Make sure the virtualization servers are up to providing proper security between instances and from the network and then scrap all that stuff in the guest OS.

LMAO @ U tomhudson 4 another moddown!

[Anonymous Coward]

Everyone now knows what U trolltalk.com jokes do around here tomhudson:

http://www.google.com/search?hl=en&source=hp&q=tomhudson+site%3A+trolltalk.com&btnG=Google+Search

In upward moderating yourselves in packs, and downmoderating others.

Proof of that is here:

http://slashdot.org/comments.pl?sid=2245866&cid=36491652

And yes, countertrolling's yet another trolltalk.com trolling scumbag infesting this forums along with the "trolling likes of YOU" as well:

http://www.google.com/search?hl=en&source=hp&q=countertrolling+site%3A+trolltalk.com&btnG=Google+Search

Get used to it scumbag. You only did it to yourselves. You are now going to be modded down for your bullshit it seems that you and your trolltalk.com pals do here constantly to others in addition to ac reply stalking & trolling them:

PROOF in your OWN WORDS, tomhudson:

---

#1

"Wait until he starts on another kick, then reply to him as an AC. It's the new meme". - by tomhudson (43916) on Sunday May 09 2010, @08:29PM (#32150544) Homepage Journal

QUOTED VERBATIM FROM -> http://slashdot.org/comments.pl?sid=1646272&cid=32150544

---

#2

HOWTO: trolling the hosts file guy in one easy step

"The next time you see a post by him, just reply anonymously. And to really mess with his head, reply anonymously to your anonymous post, disagreeing with your first anon post (extra points if you claim in the second post that you're him - that REALLY sets him off). He'll accuse you of being me" - by tomhudson (43916) on Saturday April 16, @01:38PM (#35841122) Homepage Journal

QUOTED VERBATIM FROM -> http://slashdot.org/comments.pl?sid=2086424&cid=35841122

---

#3

"if you're going to tell this guy to stop spamming his hosts file crap, make sure you do it anonymously" - by tomhudson (43916) on Saturday April 16, @12:45PM (#35840680) Homepage Journal

QUOTED VERBATIM FROM -> http://slashdot.org/comments.pl?sid=2086920&cid=35840680

---

You only did this, to yourself, tomhudson...

Added proof of tomhudson @ trolltalk.com

[Anonymous Coward]

QUOTED VERBATIM FROM -> http://slashdot.org/comments.pl?sid=2250914&cid=36531394

(From webmistressrachel, tomhudson's pal in fact)

I really want to stress this to you apk, (and whilst doing so needle tomhudson about it!) trolltalk isn't a forum anymore. It's an advert for TomHudson - by webmistressrachel (903577) on Wednesday June 22, @01:28PM (#36531394) Journal

That really truly "puts the FINAL nail in your coffins", bigtime - lol, & from "one of your own" no less...

Want more? YOU GOT IT!

Here's more, from your friend Jeremiah Cornelius, another trolltalk.com member, & pal to tomhudson also, from that very same exchange (after webmistressrachel tried to say there's no forums there on trolltalk.com no less):

http://slashdot.org/comments.pl?sid=2245062&cid=36469928

PERTINENT QUOTE/EXCEPT:

"Join us all on Troll Talk, this Tues. ;-)" - by Jeremiah Cornelius (137) on Thursday June 16, @08:26PM (#36469928) Homepage Journal

APK

P.S.=> Proof's in the pudding... apk

Why tomhudson hates HOSTS files (greed)

[Anonymous Coward]

tomhudson = GREEDY ADVERTISER!!! Proof's below, & thank-you webmistressrachel:

I really want to stress this to you apk, (and whilst doing so needle tomhudson about it!) trolltalk isn't a forum anymore. It's an advert for TomHudson's...software. - by webmistressrachel (903577) on Wednesday June 22, @01:28PM (#36531394) Journal

QUOTED FROM -> http://slashdot.org/comments.pl?sid=2250914&cid=36531394

This is just like how GMHOWELL's name came up from Jeremiah Cornelius telling me his 1st name was George while JC trolled me no less (that's there in that exchange also)...

MOST amusing how you trolltalk.com fools are "spilling the beans" on one another as I question you people from trolltalk.com, & everytime... lol!

(Hilarious but... that's what you get for being obnoxious trolls whose motivation is GREED apparently!)

---

TOM HUDSON'S "FAIL LIST" ON DISPROVING MY POINTS ON HOSTS FILES NUMEROUS TIMES:

(Since HOSTS can block adverts online/adbanners so you get more speed, &, so you are protected vs. malicious content in online adbanners also)

---

tomhudson bullshit on HOSTS is outnumbered 30:1 vs. apk evidences:

http://slashdot.org/comments.pl?sid=2087330&cid=35847946

---

tomhudson BURNED on DNS vs. HOSTS and CPU cycles/memory & more used on HIS "ideas" vs. HOSTS vs. apk's ideas:

http://slashdot.org/comments.pl?sid=2087330&cid=35879374

---

tomhudson BURNED & RAN on HOSTS vs. VIRUSES vs. myself yet again:

http://slashdot.org/comments.pl?sid=2088808&cid=35877448

---

tomhudson says "hosts are so 90's" & apk's fellow RESPECTED security person wrote a noted article on them in 2009: (based on his readings of MY posts in forums no less)

http://slashdot.org/comments.pl?sid=2088808&cid=35876806

---

And others also...

APK

P.S.=> Which is WHY of course, tomhudson began his tirade to try to libel myself here and stalk me as well on this forums... he hates HOSTS because they can be used to block out adverts online (which in turn, speeds one up massively, and, can protect one vs. malicious code in adbanners too from 1 easily edited text file):

PROOF/EVIDENCES THEREOF in tomhudson calling me the HOSTS FILE TROLL etc. & stating to his trolltalk.com pals to stalk & troll me via AC replies:

---

"Wait until he starts on another kick, then reply to him as an AC. It's the new meme". - by tomhudson (43916) on Sunday May 09 2010, @08:29PM (#32150544) Homepage Journal

QUOTED VERBATIM FROM -> http://slashdot.org/comments.pl?sid=1646272&cid=32150544

---

#2

HOWTO: trolling the hosts file guy in one easy step

"The next time you see a post by him, just reply anonymously. And to really mess with his head, reply anonymously to your anonymous post, disagreeing with your first anon post (extra points if you claim in the second post that you're him - that REALLY sets him off). He'll accuse you of being me" - by tomhudson (43916) on Saturday April 16, @01:38PM (#35841122) Homepage Journal

QUOTED VERBATIM FROM -> http://slashdot.org/comments.pl?sid=2086424&cid=35841122

---

#3

"if you're going to tell this guy to stop spamming his hosts file crap, make su

centrifuge lab

[Anonymous Coward]

centrifuge centrifuge lab
Lab centrifuge
centrifuge machine
Medical centrifuges
Laboratory centrifuges
Laboratory centrifuge
Cytocentrifuges
cell smear centrifuge
Urine Centrifuge
urine sediment centrifuge
high speed centrifuge manufacturers
centrifuge refrigerated
refrigerated centrifuge manufacturers