Question

I’m really new to Linux. I Google’d for couple of days, and installed Java and Tomcat in CentOS.

Now I need a user, that has all privileges in their home directory (including files, subdirs and files in subdirs), but cannot access any other dir.

Also this user has to have a permission to manage one service (I created tomcat service, which I can ‘start’,’stop’ and ‘restart’).

Can anyone explain how to do this?

Answer 1

You’ve asked for a lot.

There’s a few approaches possible:

• Entirely with "native" Linux permissions
• Using a mandatory access control system

Native Linux permissions

Create this new user their own new group. Make them the only member of this group.

Remove world read, write, execute permissions on all your data files. If any users were getting their privileges to the data files via world permissions, either create new groups for all the users and data as appropriate (maybe one for accounting, one for billing, one for sales, one for engineering, etc. Whatever works.)

Add a new sudoers(5) entry for this user for the sudo stop tomcat, sudo start tomcat, sudo restart tomcat, sudo status tomcat — or whichever commands this user will need to execute to manage the tomcat service. See visudo(8) for details on editing the sudo(8) config file.

If you really want to lock this user down, copy in the utilities that this person will need into their ~/bin/ dir and then proceed to remove the world execute bit on /bin, /sbin, /usr/bin, /usr/sbin. (Leave /lib, /usr/lib, etc. alone — copying in the libraries this user will need is doubtless a lot of work.)

Mandatory access controls

I’ll explain this using the AppArmor system; I’ve worked on AppArmor for over a decade, and it is the system I know best. There are more choices: TOMOYO, SMACK, and SELinux are all excellent tools. AppArmor and TOMOYO work on the idea that you confine access to pathnames. SMACK and SELinux work on the idea that every object on the system is assigned a label and the policy specifies which labels (on processes) can read, write, execute, etc. labels (on data or other processes). If you wanted to enforce a comprehensive Open, Classified, Secret, Top Secret style of protection, SMACK or SELinux would be the better tools. If you want to confine some programs to some files, AppArmor or TOMOYO would be the better tools.

AppArmor should come ready-to-use on most Ubuntu, SUSE, PLD, Annvix, Mandriva, and Pardus distributions.

The AppArmor system confines processes and controls how processes can move from domain to domain when the processes execute new programs. Domains are usually assigned by program.

The easiest way to get started is to copy /bin/bash to /bin/jail_bash (or some other name not in /etc/shells), set the shell for the user in /etc/passwd (chsh(1) can make this easy), and create an AppArmor profile for /bin/jail_bash that allows only the actions you want to allow. If we confine the process correctly, then the user cannot escape the profile we make for them.

Add a new sudoers(5) entry for this user for the sudo stop tomcat, sudo start tomcat, sudo restart tomcat, sudo status tomcat — or whichever commands this user will need to execute to manage the tomcat service. See visudo(8) for details on editing the sudo(8) config file.

In one terminal, run aa-genprof jail_bash. In another terminal, log in as the user (or otherwise run /bin/jail_bash) and begin doing tasks that you want to allow the person to do. We’ll use what you do as training material to build a profile iteratively. You might be interested to watch /var/log/syslog or /var/log/audit/audit.log (if you have the auditd package installed) to see what operations AppArmor notices your program doing. Don’t do too much at once — just a few new things per iteration.

In the aa-genprof terminal, answer the questions as they come up. Allow what needs to be allowed. Deny what ought to be denied. When you are asked about execution privileges, prefer inherit or child over profile. (The profile option will influence every one else on the system. Inherit or child will only influence executions from whatever profile you’re currently working on improving. Child breaks apart privileges into smaller pieces, while inherit keeps permissions in larger profiles. Prefer inherit for this case.)

Once you get to questions about executing tomcat, use the unconfined execute privilege. This is dangerous — if a bug in the way tomcat is started allows people to start unconfined shells, then this can be used to break out of the jail. You could confine tomcat (and this is even a good idea — tomcat isn’t perfect) to prevent this from being an escape route, but that is probably not necessary right away.

AppArmor is designed to make it easy to grow the profiles on a system over time. AppArmor isn’t applicable to all security situations, but we deployed scenarios very similar to this at the DEF CON Capture-the-flag hacking contest with excellent results. We had to allow fellow attackers root (and ephemeral user accounts) access to the machine via telnet, as well as POP3, SMTP, HTTP+CGI, and FTP.

Be sure to hand-inspect the profiles in /etc/apparmor.d/ before allowing your user to log in. You can fix anything you want with a plain text editor; run /etc/init.d/apparmor restart to reload all profiles (and unload the profiles you might remove).

It’s handy to keep an unconfined root sash(1) shell open when you’re first learning how to configure AppArmor. If you ignore the warning about programs that shouldn’t have their own profile, it might be difficult to get back into your own system. (Don’t forget about booting with init=/bin/sh in the worst of situations.)