Hi,

I am configuring sudoers so that some users can do "vi" and "nano" against any file except shadow and sudoers files. I have the following contents in /etc/sudoers file.

But still, sudoers is allowing those users to view /etc/shadow and /etc/sudoers file. Any ideas what could be going wrong ?

Do NOT give sudo access to vi!!!

vi has an escape to shell (:!/bin/bash). When the user does that they are root and can issue any command they want from the shell they just opened. (I don't use nano but my guess is that it has similar capabilities.)

2 members found this post helpful.

As long as sudo was compiled with the capability, and the os supports it, you can block shell escapes via dynamically linked executables.

There are also safer options over vim such as sudoedit.

I'm not saying I condone the 'sudo vi', however I felt the OP deserved a little bit more information than just don't do it.

nomb

2 members found this post helpful.

Agreed! This is a very, very, very bad idea. Even if you use "protections" that "gaurantee" they can't escape out to a shell.

Good info but the OP really needs to understand the man page in full especially the section: PREVENTING SHELL ESCAPES. On an HP-UX and a CentOS Linux system I just tested neither had this feature compiled into the distribution sudo so using NOEXEC wouldn't work and would give a false sense of security.

My prohibition was based on the fact that I used to work at a place where they blindly gave "sudo vi" without thinking of the consequences. Trying to undo that once given was like trying to get Congress to pass a law.

I understand where you are coming from 100%. I work in similar conditions. At least until I took over. Muahahaha. As I said I would try a different approach than give vi sudo access at all. But I also wanted to bring up other alternatives just in case. And yes the OP should go and read the man page about preventing shell escapes.

I really like the idea behind sudoedit.

Also, keep in mind, even if they can't escape to a shell in vi:
both work quite well. This goes for just about any editor program -- if you let someone run a shell or an editor as root, you've better assume they have root for everything.

1 members found this post helpful.

Isn't this the perfect scenario to use rvim? Or would that not work well either?

Just out of curiosity, there's nothing permissions-wise you could do to grant your users the access they need?
What *NIX distribution does this pertain to, maybe filesystem-based Access Control Logs are the way to go?

Another angle to consider, are your users "appending" the files in question? Maybe you could just have them pound out things into a file, then run a script that appends the text to a given file?

P.S: I wonder why we haven't heard back from the Original Poster in almost 5 days...

I thought that once upon a time but on doing testing long ago found that running restricted vi as root essentially is the same as running regular vi. I haven't tested vim the same way but suspect it may be the same.

My last job actually gave sudo access to vi until one guy decided to notify our department that he could break out into a root shell. It's not like that's a secret or we were unaware, it was more of a trust thing. So anyway, his notification changed that and the solution was to use rvim instead. The guy who notified us of this thought he was a hotshot, so I'm sure he would have loved to tell us again that rvim allowed a root shell too. So I'd say it worked. But now I'm really curious! I would tell the OP to try it and let us know, but I think his actual problem is with sudo syntax not whether or not his co-workers can break out into a shell. And I don't see a problem with the syntax...

Funny that - At the same place where they were doing the "sudo vi" a developer once reported to our management that there were several security holes in our UNIX setup. They sent me to discuss it with him. After discussing everything he'd found with him I went back and told my management that they needed to either:
A) Force him to transfer to our department so he'd be with us or
B) Fire him so he didn't have access to the servers on our LAN as we'd never be able to block anyone as smart as him.