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.

[LordVader]

@iago:
What I take away from that isn't so much about specific programs that can or will potentially be exploited but as always falls back to admins,users and their actions in an environment..
Which can result in malicious code execution leading to the whole environment being compromised.

For me personally I'm not one to live in fear of such things happening and not do or provide what I normally would in  "ideal" situations, both in real life and in things like this.
So that brings me more or less back to the original question of what would most people consider fairly safe must have tools, that you would want to have access to ideally for web/personal use.

Also raises a second question based off the assumption that at some point the chroot environment can possibly fail.. and how to best protect you're network and the outside world from the consiquences of such a failure.

My general experience would say:
1) Descent router/firewall setup that seperates the "Public" servers that are potentially vulnerable, from the rest of you're network.
2) Active anti virus, rootkit, other scanning.
3) Active Security Auditing.
4) Staying aware and upto date with security information in general.
5) Backups, and more Backups.. did I mention backups?

Would provide a fairly descent margin for error/failure on the public frontend servers, that could be restored, updated and fixed if something did go bad.

Anyway this is very helpfull to me im fairly new to bsd/*nix, less then a year but im not one to do things without doing research so i've learned alot and still learning..
Things like this help me make sure im clear and approaching things correctly..
As always thanks for the input it's always appreciated..

Any idea's/suggestions/critique to further things is always welcome.

@nslay:
That is correct no su or sudo access i'm trying to provide direct chrooted access to only specific tools in a webserver environment.
Thru a control panel (ispconfig) I create users, and can assign them ftp/email/ssh/other access etc. all chrooted.
So personally i'm looking to find out what may be considered safe to provide for users, that may aid in editing html or setting up php scripts/software, which is why I was asking about nano/vim etc.
But also the general discussion about chroot in general and using apps and the security ramifications are also very welcome it's good to know and read for me, and im sure others also.

[nslay]

Don't forget the securelevels in BSD, and there is rootkit driver developed to combat rootkits in Linux.  I don't remember what it was called, but it was released at defcon.

[LordVader]

What I have gathered mostly so far..

Ping:
Can be sketchy as it does exec higher priv's internally and may lead to bad things, not to mention the things users can do with ping so to provide/use at own risk.

Nano/Vim:
Outside of the "unknown" would generally be considered safe in themselve's, but may lead to bad things if something unknown or unexpected compromises the chroot environment or raises priv. levels etc..

Other:
Mostly the same as nano/vim, use with caution find out what they are and how they execute and handle user priv's interally, and follow the previous guildlines and you can be fairly confident what to and not to use.


As well as generally doing research, learning how to be a descent admin and staying ontop of things as I mentioned previously as always.

[iago]

Just for the record, my posts in this thread weren't referring to a chrooted environment, but only to potential vulnerabilities in vim.

If vim can be exploited, and the user has su/sudo access, then there's a very good chance of obtaining root.

[LordVader]

@iago:
So making sure to seperate any tools from su/sudo by not providing su/sudo in a chroot environment "should" for the most part limit the risk of abuse correct?

*Edit: in general and specifically in regards to vim etc.

[nslay]

You know, if you're really worried about keeping up with known vulnerabilities
I recommend Free/OpenBSD with portaudit installed.  portaudit will automatically audit the installed applications for known vulnerabilities.
Here's an example output:

LIGHTBULB# portaudit -Fda
auditfile.tbz                                 100% of   42 kB  119 kBps
New database installed.
Database created: Tue May 29 11:40:06 EDT 2007
0 problem(s) in your installed packages found.

Also, subscribing to the announcement/security mailing list will keep up to date on vulnerabilities in the Free/OpenBSD kernel and userland.

[LordVader]

Yes at some point I fully intend to shift to freebsd or openbsd, but im still learning and currently am depending on a control panel "ispconfig" on debian linux to help automate user creation and such for my web environemt.

I have several different systems setup in vmware and constantly am playing but currently for what I need debian + ispconfig is the best solution i've found for hosting domains/users etc..

At some point i'm going to shift from paid hosting to hosting all my sites myself and possibly a friend or two as needed, which at that point I do hope to be walking outside of ispconfig and linux and on freebsd or openbsd

I'm soso on freebsd now as far as using ports, cvsup etc, portmanager/portupgrade/portaudit etc..
But as far as running a live server environment and automating usercreation and such..
eg: one script or form to create users for several different apps in a controled environment etc..
I'm far from that yet.. but im learning and headed in that direction =)

I use these sites as a reference for most things *nix related:
http://www.bsdguides.org, http://www.bsdguides.org/guides <<-- for "bsd's"
http://www.howtoforge.com/ <<-- for various linux distro's and some bsd stuff.
www.google.com && www.ask.com <-- for everything else, or stuff I can't find on those sites.

[iago]

@iago:
So making sure to seperate any tools from su/sudo by not providing su/sudo in a chroot environment "should" for the most part limit the risk of abuse correct?

*Edit: in general and specifically in regards to vim etc.

Yes, let me just highlight the important points of my last post:

Just for the record, my posts in this thread weren't referring to a chrooted environment, but only to potential vulnerabilities in vim.

If vim can be exploited, and the user has su/sudo access, then there's a very good chance of obtaining root.

So yes, if you don't have users with administrative accounts, you're fine. I'm talking about a totally different situation.