Safe Chrooted SSH Environments

[LordVader]

What would you guys consider safe as far as a list of apps goes, mainly looking for what would be considered:
"Must have apps"
like nano/vim etc..

Don't need to list core things like unzip/zip/tar etc.
I'm more interested in other apps that help ssh be descently usable for general users but not overboard and risky.
Keeping in mind that the more that get's added raises the risk of exploits to break out of chroot..
so minimal is good.. but still usable average users wanting to do some editing and the like.

[Newby]

Ehh, text editors like vim are pretty risky (at least FreeBSD keeps telling me that when I install it). Get root with vim, and you win. Especially since vim has a shell command in it.

[LordVader]

True, but if we do a good job setting up the chroot environment are there any you would consider safe enuff to allow a user to use?

And what about other tools is there any you would consider necessary if you had a user acct on a website, and that came with email,ssh,ftp login etc..
Would you be fine being forced to use ftp to to do all editing thru or would you want wget/nano/vim(similar)..

I realise not having the editor is the safer route but looking for possible idea's on what could be somewhat safe as far as extra tools go, and also what ppl consider "must have tools" beyond tar/zip type apps in ssh etc.

So ppl know what I consider core my current apps listing for the chroot web ssh environments:
APPS="/usr/bin/mysqldump /usr/bin/mysql /usr/lib/openssh/sftp-server /bin/bash /bin/ls /bin/cp /bin/mkdir /bin/mv /bin/pwd /bin/rm /usr/bin/id /usr/bin/ssh /bin/ping /usr/bin/unzip /usr/bin/zip /bin/tar /usr/bin/dircolors /usr/bin/wget"

[nslay]

Ehh, text editors like vim are pretty risky (at least FreeBSD keeps telling me that when I install it). Get root with vim, and you win. Especially since vim has a shell command in it.

What?

vim is safe...its applications that require suid or root privileges to run that you want to be careful with, especially those that accept remote connections.

[LordVader]

Ehh, text editors like vim are pretty risky (at least FreeBSD keeps telling me that when I install it). Get root with vim, and you win. Especially since vim has a shell command in it.

What?

vim is safe...its applications that require suid or root privileges to run that you want to be careful with, especially those that accept remote connections.

@nslay:
So outside of unforseen exploits in vim/nano/other generally safe use apps causing them them directly get root or suid(0/1) priv's, you don't see a problem?

So I guess as long as the app is fairly secure in itself and run as the user and not root/suid(0/1) etc.
It would be considered fairly safe to allow a user access to..
Keeping in mind backups can reverse most dmg if something did happen, then just figure out what happend and remove or fix the app used that caused the failure..

[nslay]

Ehh, text editors like vim are pretty risky (at least FreeBSD keeps telling me that when I install it). Get root with vim, and you win. Especially since vim has a shell command in it.

What?

vim is safe...its applications that require suid or root privileges to run that you want to be careful with, especially those that accept remote connections.

@nslay:
So outside of unforseen exploits in vim/nano/other generally safe use apps causing them them directly get root or suid(0/1) priv's, you don't see a problem?

So I guess as long as the app is fairly secure in itself and run as the user and not root/suid(0/1) etc.
It would be considered fairly safe to allow a user access to..
Keeping in mind backups can reverse most dmg if something did happen, then just figure out what happend and remove or fix the app used that caused the failure..

vim doesn't need suid to run.  Exploiting vim gets you nothing unless root happens to be running the vim you exploited.
The reason I note suid applications are dangerous is because exploiting those can get you root privileges ... vim is not one of these.
An example of a suid application is ping

107 16526 -r-sr-xr-x 1 root wheel 68360 23296 "May 24 19:38:52 2007" "Feb  4 04:10:46 2007" "Feb  4 04:10:46 2007" "Feb  4 04:10:46 2007" 4096 48 0 /sbin/ping

You may notice many shell providers do not have ping for that and other reasons

[LordVader]

Ahh good to know, from what I can see when I:
ps aux

I see ping being executed by the user that executed ping, not root/suid(0) so I'm assuming it's safe on my system..
eg not using root/suid(0)

Tho I may be mistaken..

This is on a debian linux box.

[nslay]

Ahh good to know, from what I can see when I:
ps aux

I see ping being executed by the user that executed ping, not root/suid(0) so I'm assuming it's safe on my system..
eg not using root/suid(0)

Tho I may be mistaken..

This is on a debian linux box.

That's because ping resigns root privileges after attaining a SOCK_RAW socket. (if you're curious how that works, man setuid(2))
EDIT: That doesn't mean ping is 100% free of exploits...the getopt() functionality used by ping to parse command line arguments, for example, might have some sort of buffer overflow somewhere. (see getopt(3))

[LordVader]

Thx for the info, very helpfull.

[Newby]

vim doesn't need suid to run.  Exploiting vim gets you nothing unless root happens to be running the vim you exploited.
The reason I note suid applications are dangerous is because exploiting those can get you root privileges ... vim is not one of these.

What if the exploit is something of an overflow and some shellcode escalates your privileges and gets you root?

Ohyeah: no compiler on your chrooted environment, either.

[iago]

What if the exploit is something of an overflow and some shellcode escalates your privileges and gets you root?

Because that's an extremely unlikely situation.

If it's considered dangerous, it probably means that it's dangerous to give it suid or sudo access, since shell commands can be run through it (:!ls).

vim doesn't need suid to run.  Exploiting vim gets you nothing unless root happens to be running the vim you exploited.
The reason I note suid applications are dangerous is because exploiting those can get you root privileges ... vim is not one of these.

Well, if somebody sends you a malicious textfile, and you opened it, and it exploited vim as your user account, it's game over. Once something has access to your user, it's a small jump for it to get access to root. I'd link to a blog I just wrote about that, but it's not published yet.

[nslay]

What if the exploit is something of an overflow and some shellcode escalates your privileges and gets you root?

Because that's an extremely unlikely situation.

If it's considered dangerous, it probably means that it's dangerous to give it suid or sudo access, since shell commands can be run through it (:!ls).

vim doesn't need suid to run.  Exploiting vim gets you nothing unless root happens to be running the vim you exploited.
The reason I note suid applications are dangerous is because exploiting those can get you root privileges ... vim is not one of these.

Well, if somebody sends you a malicious textfile, and you opened it, and it exploited vim as your user account, it's game over. Once something has access to your user, it's a small jump for it to get access to root. I'd link to a blog I just wrote about that, but it's not published yet.

That's not true at all, it's not a simple jump.  Thats the point of root vs user!  There are many public shells available, none of which are routinely exploited as you suggest.  Big deal if a user is exploited?
I know Linux is infamous for being the Windows of the Unix world, and I love to cite SDF's (Public Access Unix, est. 1987) bad security experiences with Linux, but this is not generally true among other flavors of Unix!

[nslay]

vim doesn't need suid to run.  Exploiting vim gets you nothing unless root happens to be running the vim you exploited.
The reason I note suid applications are dangerous is because exploiting those can get you root privileges ... vim is not one of these.

What if the exploit is something of an overflow and some shellcode escalates your privileges and gets you root?

Ohyeah: no compiler on your chrooted environment, either.

Nothing wrong with compilers either.

[iago]

That's not true at all, it's not a simple jump.  Thats the point of root vs user!  There are many public shells available, none of which are routinely exploited as you suggest.  Big deal if a user is exploited?
I know Linux is infamous for being the Windows of the Unix world, and I love to cite SDF's (Public Access Unix, est. 1987) bad security experiences with Linux, but this is not generally true among other flavors of Unix!

If your user account gets exploited, it can alter the running instance of bash (or ksh, sh, zsh, whatever). The next time you run "su" or "sudo", it can redirect the command and grab root.

It is very hard to defend against that attack, and I don't really think it's possible in all cases.

I'm going to ask the editor to post my blog for tomorrow, where I discuss that attack.

<Edit> nevermind, it posted this morning! http://www.symantec.com/enterprise/security_response/weblog/2007/05/the_danger_of_speling_mistakes.html

Basically, it outlines two really simple attacks on "sudo". And these attacks aren't a weakness in sudo, they're a weakness in multi-user separation.

[nslay]

That's not true at all, it's not a simple jump.  Thats the point of root vs user!  There are many public shells available, none of which are routinely exploited as you suggest.  Big deal if a user is exploited?
I know Linux is infamous for being the Windows of the Unix world, and I love to cite SDF's (Public Access Unix, est. 1987) bad security experiences with Linux, but this is not generally true among other flavors of Unix!

If your user account gets exploited, it can alter the running instance of bash (or ksh, sh, zsh, whatever). The next time you run "su" or "sudo", it can redirect the command and grab root.

It is very hard to defend against that attack, and I don't really think it's possible in all cases.

I'm going to ask the editor to post my blog for tomorrow, where I discuss that attack.

<Edit> nevermind, it posted this morning! http://www.symantec.com/enterprise/security_response/weblog/2007/05/the_danger_of_speling_mistakes.html

Basically, it outlines two really simple attacks on "sudo". And these attacks aren't a weakness in sudo, they're a weakness in multi-user separation.

From the sound of it, it doesn't seem he is going to give su or sudo access to his users.
P.S. sudo sucks. su + wheel forever.