chroot or keeping users to /home

techrolla · 05-31-2004, 11:49 PM

I was wondering how I could change permissions, or the root for all of the users in the "hosted" group? I don't want the users in the group to be able to move around the system except in the /home directory. I checked out other topics, but they were a little vague...thanks.

unSpawn · 06-03-2004, 12:22 PM

May I ask why? Did you check out the LQ FAQ: Security references, post #4: Chroot, chrooting, jailing, comparimization?

techrolla · 06-03-2004, 03:54 PM

Thank you, I will look into that. To answer your question...I am a relatively new linux user, about half a year now, and I have some of my friends sites hosted from my server and I offer ssh and ftp access. My problem is, though, that when I was really new with linux and didn't totally understand permissions, I would chmod 777 everything, which was really stupid, so I want to keep the boys locked up until I fix my own wrongs and secure my system. I also don't want some of them fucking around in there, however much they are actually able to do. Thanks, though.

unSpawn · 06-03-2004, 04:20 PM

My problem is, though, that when I was really new with linux and didn't totally understand permissions, I would chmod 777 everything
Weird how the meaning of a question changes when ppl tell you the *real* reason for wanting something...
#Note this isn't directed at you, just an observation.

until I fix my own wrongs and secure my system.
If it's a box using rpm package management you're in luck. This isn't the forum for non-security stuff, but OK. Here's an easy Bash script I wrote for just this kind of situation:

Code:

#!/bin/bash
# Purpose: Restore filesystem permissions from RPM database
#          distro's that don't do package management suck.
# Args: none or package name
# Deps: Bash, GNU utils, rpm
# Run from: manual, emergency only

case "$#" in
0) rpmopt="a"; unset pkg;;
*) unset rpmopt; pkg="$1";;
esac

rpm -q${rpmopt} --dump ${pkg}|while read t; do
        t=( ${t} ); for i in 3 4; do
        case "${#t[$i]}" in 7)
                echo "chmod ${t[$i]:3:4} ${t[0]}"
                echo "chown ${t[5]}.${t[6]} ${t[0]}";;
        esac; done
done

Notice this tool by design doesn't restore perms but only echoes the commands.
You'll have to pipe output to a file and run that.

techrolla · 06-03-2004, 04:37 PM

Thanks, I am running the script right now...but I just wanted to add that although I fear for my system with other users because of my past wrongs, I also want to keep the users out of my system because the computer is my only server and it's my personal system. It is not dedicated to user accounts and hosting, so I want their uses to be separate from mine, even though I can change permissions for them, and I have, I still want them jailed in, atleast for now...Thanks, I will respond with questions to the script.

unSpawn · 06-03-2004, 04:40 PM

OK. So what tasks are they allowed to perform within the jail?

techrolla · 06-03-2004, 05:00 PM

So I just run the piped file and that should set permissions back to an acceptable level?

techrolla · 06-03-2004, 05:03 PM

Quote:

Originally posted by unSpawn
OK. So what tasks are they allowed to perform within the jail?

Well, pretty much anything. I maybe don't want them having access to gcc just incase someone comes in and compliles and runs a file to break a chroot, which I have seen. Other than that, I want them to have access to most of the programs, I don't think many of them will really ever use the shell, so I don't know how much of a problem that would be. Just maybe gcc.

unSpawn · 06-03-2004, 05:48 PM

Well, pretty much anything.
A chroot *can* work for a limited set of apps but not all because this would mean you would have to install them all in each users home. What I could suggest is run UML (user-mode-linux.sourceforge.net, UML puts users in a virtual Linux "cage" which means they can't hurt the underlying system) or install the GRSecurity kernel patch. The GRSecurity kernel patch allows for process separation (users can't see other users processes), Trusted Path Execution (users can't execute apps outside of $PATH), extensive chroot facilities, process ACL's, auditing and logging and much more. If you run UML users can't hurt the system but I don't know how difficult it is to get up and running (still have to try), if you decide to go for GRSecurity you'll still need additional measures in place like explicitly allowing/denying people access to some services/apps tru Firewall, hosts.deny, PAM, user/group chowned binaries, sudo etc etc.

neo.dot · 06-22-2004, 05:18 AM

my friend your are great !!!!soon or later , this will help to our future job regarding security..

what i need now ,lets focus only to redhat linux 9 this is were the game plays.

one by one lets dissect .what we can learn fr. redhat linux 9..

thanks very much.....