Hi

is there any shell rather than bash for RH7.2-3, that would prevent users remotly logged in from reading files that are not in their respective directories, regardless of the dir/file permissions ?!


NetGeek

This has been discussed at length on these boards and others. Do a search for 'permissions chmod home shell' or something similar. It's not bash that's the problem, it's the filesystem perms.

The best solution is to chroot() shell sessions, but not many syadmins have technical skills to do it :D

Originally posted by magnafix
The best solution is to chroot() shell sessions, but not many syadmins have technical skills to do it :D

chroot() jails are not the answer to this problem, as seen from many *many* exploits that have been written and tried and tested, getting the better of chroot() jails can be trivial. Even when secured by who ever thinks they are the best sysadmin, they can be easily gotten out of. :)

But a properly setup filesystem, a proper system umask (god knows why some distros of unix have 002 as the umask) and tight reigns on your users can be very helpfull. Also keeping fscking [l]users home dirs drwx-----x is a good idea. Force this with a daily cronjob to stop nosey users sniffing about. For this to work all users with shell access should be in the same group and their home dir's should all be group owned by that group.

Filesystem security is a huge step in the right direction. like /var/tmp and /tmp should be mounted nosuid,nosgid,noexec etc. in the past we have seen many explots come from /tmp... purely cause its world writeable and have have executable files and suid files etc.

</rant>

Regards,

paul

Paul,

I'd love to test some of these chroot() breakout exploits on our system -- got a link or two?

Originally posted by NetGeek
Hi

is there any shell rather than bash for RH7.2-3, that would prevent users remotly logged in from reading files that are not in their respective directories, regardless of the dir/file permissions ?!


NetGeek

You can write your own shell to do that if you have good knowledge of C. Who knows - if you make it good enough, you can sell it to hosts who want to implement extra shell security...

hmm.... that's a good idea... I might do it if I get more time to look into it ;)

I agree that while chroot jails are good for most users, people can break out of them if they know what they are doing. Permissions, ownership and other such things are the best solution. You can deny user's from reading almost any file they can get information from so no one can see what domains are on the system, they can't get into other user's home directories at all by any method (shell, FTP, CGI or PHP), or get any other information.

The most they can get is the contents of the passwd and group files to see what other users account names are on the system, which does them no good other than to maybe try and use a password cracker against the accounts (but that is trivial and you would implement a method to lock out any account trying such an attack on other local users, and you would make it impossible for such remote brute force attacks). They can't access any other information and they can't access any user's files or directories.

Those are the key elements and the best solution. Between that and other policies and keeping the system secure and well configured and patched/updated, there's nothing anyone can really do and you needn't bother with a chroot jail for even a trivial solution. You can then modify certain shell environments to allow anyone by specific processes spawned in specific ways from accessing the passwd and group files even, and you can easily do the same for process listing (not just denying them access to the actual tools (although that's helpful to a point, but they can upload their own copy otherwise and bypass your access rules), but the actual environment). Some kernel security patches can accomplish this.

However for the main part of the question, as other's have said, this has been discussed to death on this forum alone and many other sources on the web. There's also a few ways to deal with this, even without a jailing method. I won't try and explain any technical issues involved, as it would simply be too involved and it's partly a matter of choice in how and what you implement. If you like, I might be willing to demonstrate these ideas and solutions on a demo account for you on my servers. In fact, I forgot a person was saying they could crash my server by overloading it and I offered them to try it so I could example the solutions for process control. I need to contact them and while I'm at it, perhaps I can example some solutions to your question too.

I wanted to add to the above, and mention that with the right services and software (common, best choices actually), you will not even need to allow shell access for most users listed in the passwd file. You can have completely usernames and passwords for FTP, Email, etc. from their main account passwords (i.e., for accounts without the need for shell access, you don't allow them any way to log into shell and you needn't even set a password to allow them to be able to log into shell even if they were allowed, without a password and a valid login, yet still allow all other services to them).

Also, if you do offer shell access for the main account itself, there are methods to prevent attacks on them remotely and locally, and that's only a concern for the users with actual shell access, but there's some nice custom solutions for that too. As I said, there are many ways to go about this and a lot of them are simple and use secure tools already, like ProFTPD, Qmail, Vpopmail, etc. (it depends on what you run and how it's set up) and other software that allows for custom configurations to not use the passwd files for the service to run or authenticate the users.

Therefore other software like Exim, wu-ftp (but you'd not want to use that anyway), postfix, etc. will work as well for the simple solutions -- it's just that things like Qmail outperform and are more secure than the alternatives. On a reasonably well configured and secure system, things such as chrooting users shell logins will be trivial and probably not offer any added security when it comes down to it. Again, without getting into any details, because there's really a lot to it, even if it's nothing THAT complicated if you have experience -- I just don't think I'd be able to explain it well.

Originally posted by magnafix
Paul,

I'd love to test some of these chroot() breakout exploits on our system -- got a link or two?

Linking to such things on a public forum wouldnt be quite ethical IMO. But google can help quite a bit to find them.

IMO any chroot() jail can be broken out of. Its only a matter of finding a flaw in the system in use. I am not a programmer and Id doubt id be able to do this, but i've seen them in action.

As said previously, its down to permissions etc. There is a lot that can be done to achieve a secure system, but again the only secure system is a system with no users, and no net connection and is powered off :)

Regards,


Paul

Originally posted by flamegrill
...

but again the only secure system is a system with no users, and no net connection and is powered off :)



There's no reason to be so negative. :-) I think that's an extreme point of view. Some software and services have never been compromised and by looking at the source you can see why. Of course there's still many other programs and services that have exploitable flaws just waiting to be found.

Originally posted by 2host.com


There's no reason to be so negative. :-) I think that's an extreme point of view. Some software and services have never been compromised and by looking at the source you can see why. Of course there's still many other programs and services that have exploitable flaws just waiting to be found.

Agreed :)

Correct me if I'm wrong, but chroot() jails can only be broken under root account. So if the normal user attacker wants to break his chroot, he needs to get a root access first, which could be a problem under chroot environment.

Nevertheless, I don't like chroots. It is either not flexible (you can't do anything inside it) or consuming too much resources (you need to put almost everything under every chroot).

Someone has to find some way to exploit it, and yes that is often a root exploit. That doesn't make it any easier, unless the chroot jail is set up really wrong, though. :-) It's just more trouble than it's worth, but it can be useful. It all depends. It's definitely not the be all, end all solution or even close though.

I guess when I used the phrase "best solution", I meant that it makes things simple for us. On our system, users log in and they have their own /etc/passwd with three lines in it: their user, root, and www. The only purpose to /etc/passwd is to show usernames in 'ls -l'. No /etc/shadow needed. No /home to go poking around in. Their homedir is /.

This is also the perspective they have when setting up CGI/PHP scripts that read/write files, as well as logging in via FTP. Again, this makes things simple. Our users don't need to know what server they're on, or what the "real" path to their homedir is.

So far so good! :)

Indeed, it works well enough for most users. Just remember that without the web server chrooted, among other things, their CGI and PHP scripts may very well bypass this chroot jail for shell and FTP. Of course you can modify those environments to work the same way so that's not an issue, but it can get hairy. I'd rather take the other approach and simply make it useless for them to bypass the chroot jail, since they can't do anything anyway -- that's what's important.

Still, a chroot jail on top of the other ideas probably won't hurt and might add a nice finishing touch for shell (especially if you chroot the other environments). I could discuss this for days on end and what my ideas are and what I've implemented, but I've not bothered to, nor care to really implement a chroot for shell at this time, as everything else is locked down (that being the key element of course).

Well said Robert.

And yes, CGI/PHP is chrooted too, and runs as your user. That's what makes our setup simple for both us to support and customers to use.