Hello,

I am planning to use jail for the shell accounts. It is possible to configure jail in pure-ftpd, but I am having problems with SSH on Debian 6.0

I have done some research on this issue.

1. There is a package by Olivier Sessink, Jailkit: http://olivier.sessink.nl/jailkit/

I have used this package on a CentOS server, it is really good but it doesn't have user removal & package removal utility from the jail, as far as I know. Never used in Debian.

2. I have found a How to Forge article: http://www.howtoforge.com/chrooted-s...l-debian-lenny

In this article, the author discussed about an shell script doing all the work. I haven't tried it yet, but it seems it creates a basic SSH jail.

3. From Debian web site: http://www.debian.org/doc/manuals/se...sh-env.en.html

In this page, makejail application is discussed. I don't know the difference between the previous script, but it seems complicated in my opinion.

4. I think there is also "rbash" shell, but I am not really sure what it does about jailing.

I need my jail very simple. I need some file system utils (rm, mv, cp, mkdir and so on) and some utils (i.e. rsync, pico, vi), that's all.

Do you have any idea or suggestions about the jails used in Debian?

I'd go with the last link, since that does the SSH chroot jail, as you're asking for. However, I'd be curious to know what the issue is you're trying to solve. Granted, this may be a security requirement from your company, but with a small amount of caution in setting your users up, all they could read/write/modify would be things in their own directories anyway. System utilities would be accessible (like rm, mv, etc.), but again, they could only delete what they owned.

What is the problem you're trying to solve with the chroot shell?

Thank you TB0ne for the information. I was having some problems with Jailkit when I was working on my CentOS test server. The problem is, Jailkit holds a seperate passwd, group and shadow file inside the jail. I didn't like it though. Because, when you delete an account, it won't be deleted from the files inside the Jailkit jail and later on, this causes problems. Additionally, it is not possible to change user password inside Jailkit jail. Mr. Sessink suggested that one needs to use a LDAP or similar authentication methods for this issue. I am going to use LDAP for authentication, but probably Jailkit will add the user to the passwd, group and shadow inside the jail, never tried this but I don't want this to happen.

The problem is I need a jail that can operate with LDAP authentication. As you know, if you add users to LDAP server, they won't be added to the passwd, you can only see through "getent passwd" command, or "getent group", "getent shadow". Jail shouldn't be writing to any login related file and should provide command limitations.

The problem in the second link (how to forge), I need to manually add and remove users from sshd_config file. According to my research, there are no possibility to include external file from sshd_config. That is a really big downside in my case.

To be frank, I haven't tried "makejail" utility and I don't know how it will react according to the situation above. I don't want to face with the problems like in Jailkit.

I just wanted to see some opinions regarding to jailing users in Debian considering my apprehensions.

I have similar plans. I have used freebsd jails and linux openvz in the past. This time, I will take a look at lxc.

1 members found this post helpful.

I think FreeBSD jails are the ones that I need but it is impossible for me to use FreeBSD. My company only supports for Debian, and I need to find a choice for it. It is also possible that my Debian server may run under OpenVZ (I learned it today, sorry for not mentioning it before).

I will check lxc, hope it works under Debian under OpenVZ.

Nice one, Berhanie. Hadn't seen that before.

Cyrolancer, you're right about using LDAP complicating things in this scenario, but my real question is, what problem are you trying to solve by jailing your users, and what's your end-goal? There may be easier ways of accomplishing what you're after.

I am trying to limit my users to use only specified commands and utilities under Linux shell. These are some common commands, like ls, mv, cp, touch and some utilities like, rsync, pico, vi and maybe python and perl. I think python and perl make the things complicated and we can drop these for now. I am going to use LDAP (pam-ldap) or MySQL (pam-mysql) for authorization of users.

This will be a company-wide storage server. Users should have very limited priviliges and access to very limited commands and utilities. I don't want them to write a download script from one-click hosts Also, I don't them to see what is installed in the server. I prefer they don't need to see others' home folders (even their presence on the server). Limiting access to folders is a simple chmod command, I think. The reason I don't want people see others are using the server is due to company policy. Seems weird, but I need something simple enough to achieve this.

I understand what you're going for now. I know with sudo, you can easily limit what commands can be run/not run, and what users they run those commands AS. Also, sudo can tie in with LDAP, so you can have one sudoers file. Maybe you can alias the commands to have them run as "sudo <command>", and let the sudoers file do the allow/deny for you. The rest you might be able to accomplish with strict permissions on your directories. Not sure how you'd make it bulletproof, though, to keep people from getting around it by editing their .profiles.

Just a thought.

I was thinking that sudo is used for obtaining administrative privileges. According to your suggestion, it is possible to block, for example, chdir command? or limiting access to /etc folder (limit access for uids above 5000, for example)? Because limiting some commands would be painful, I need to disable all commands and enable some of them. Is it possible to do it by using sudo?

Certainly, and sudo can even let you run commands as a different user, not just root. Check the man page for the syntax.

My thought was to put something in the system-wide profile that gets run when everyone logs in, to alias the commands to have "sudo" in front of them. Something like:
would alias the "ls" command to be run as above. The sudoers file would then do the heavy-lifting of figuring out if someone was authorized to run it or not, and would be easy to administer. There's a good article about the alias command
http://www.linfo.org/alias.html

But be cautious: if you take away a users chdir command, and they have sub-directories in their home folder....how will they go into them, or go back? But again, sudo can be set up to be VERY granular. You can let someone change directories to EVERY directory, except some. Here's a snip from one of my sudoers files:
Anyone in the VENDORS group can run the things listed in the VENALLOW group, but NOT if they're listed in the VENDENY group, for example, they can't run "passwd root", but CAN run "passwd vendorguy1".

Again, this is just a thought...I've never tried to take it as far as you're trying to, and there may be much better ways of accomplishing what you're after. This is kind of a kludge, to be honest.

1 members found this post helpful.

Before reading the man page, I want to make sure some thoughts in my mind. Then, I am going to read the manual, promise

1. Is it possible to chroot everybody to their home, like in pure-ftpd? Because I don't want them to see, i.e. the sudoers file
2. Is it any way to set deny all commands and enable some of them (like in iptables you deny all and you start opening the ports). I think, using your solution, I need to disable every command one by one.
3. Well... before asking so many questions, I should read sudo manual, I think.

I am going to check your suggestion in any case. For the results, I will write here.

Thank you

Not with sudo, no. As I said, you can set permissions to be such that a user can't see another users directories, but a chroot jail is far different.
That's correct...but no matter which way you go, the list of what you're putting in to sudoers is going to be extensive. And the sudoers route is, as I said, a kludge. Use a real chroot jail if you need to. Honestly, I think you may be swatting a fly with a sledgehammer. If the users in question all work for the same company, then set them up, make sure their history files are unalterable, and be VERY prudent with your admin access. Use basic system hardening skills, and keep an eye on things...basic sysadmin stuff. If a user gets out of line, react quickly and harshly, but make sure you KNOW who did what, and be able to PROVE they did it.

Thank you TB0ne. I will be thinking about your solutions.