CHROOTING local users sshd or *

Submit your RBAC policies or suggest policy improvements

CHROOTING local users sshd or *

Postby Sharky » Sun Nov 03, 2002 11:50 pm

Hi there.
There has been posted a topic before about how would you chroot a user so that he cant breakout of his ENV.
Unfortunatly this week end I had to site back home and keep trying to build chroot ENV with the ACL system.
After a great Effort I was able to do such a thing, now IT aint perfect and few people as a matter of fact might say it's not a chroot env but i will show you the DEMO.

Steps to create a chroot Env for local users ( wethter they log via keyboard/telnet/SSH)

1) Choose your favorite shell (ksh,bash,etc..)
2) make a copy of that shell in same dir but in a new name ( for example I cp /bin/bash /bin/bash3 )
3) add bash3 to /etc/shells
4) add any user on your system and let his shell be /bin/bash3
5) Modify your ACL system with this new bash and In a LEARN MODE! its important that you add it in a learning mode
Ex ( copied of my system ) :

/bin/bash3 lo {
/h
-CAP_ALL
RES_FSIZE 0 0
RES_DATA 0 0
RES_RSS 0 0
RES_NOFILE 0 0
RES_MEMLOCK 0 0
RES_STACK 0 0
RES_AS 0 0
RES_NPROC 0 0
RES_LOCKS 0 0
connect {
disabled
}
bind {
disabled
}
}

6) Login as that user for awhile while gradm is in learning mode to inherite the state of that bash.

7) when you think its the right time , have a look at the generated ACL
8) that was the generated ACL on my system: ( the username assumed is ForEver)

**************************************************************************************************************************

/bin/bash3 o {
/usr/share/locale/locale.alias r
/usr/lib/locale/en_US/LC_CTYPE rx
/usr/bin x
/usr/X11R6/bin
/sbin/shutdown x
/sbin/ifconfig r
/sbin/consoletype x
/sbin r
/proc/meminfo r
/proc
/misc
/lib rx
/lib/ld-2.2.5.so x
/lib/i686/libc-2.2.5.so rx
/home/ForEver/.bashrc rx
/home/ForEver/.bash_profile r
/home/ForEver/.bash_logout r
/home/ForEver/.bash_history ra
/home/ForEver r
/etc/sysconfig/i18n r
/etc/profile.d rx
/etc/ld.so.cache rx
/etc r
/dev/tty rw
/dev/null w
/dev
/boot
/bin x
/bin/bash3 x
/
-CAP_ALL
RES_FSIZE 54532 54532
RES_DATA 238320 238320
RES_STACK 25576 25576
RES_RSS 0 0
RES_NPROC 6 5
RES_NOFILE 260 260
RES_MEMLOCK 0 0
RES_AS 2982176 2982176
RES_LOCKS 0 0

connect {
disabled
}

bind {
disabled
}

}


**************************************************************************************************************************
as you can see clearly that is the requirmets of the SHELL , now the user is not in a chrooted Environment but we know what FILES EXACTLY he needs so the idea of jailing is to give the USER the least Requirments needed by the system to give him a small room where he can sit. in the above ACL many things were given that should be taken off.
That's why i modified the ACL to look like :


/bin/bash3 o {
/usr/share/locale/locale.alias r
/usr/lib/locale/en_US/LC_CTYPE rx
/usr/bin x
/usr/X11R6/bin
/sbin h
/sbin/shutdown x
/sbin/ifconfig r
/sbin/consoletype x
/proc/meminfo r
/proc
/misc
/lib rx
/lib/ld-2.2.5.so x
/lib/i686/libc-2.2.5.so rx
/home h
/home/ForEver/.bashrc rx
/home/ForEver/.bash_profile r
/home/ForEver/.bash_logout r
/home/ForEver/.bash_history ra
/home/ForEver r
/etc h
/etc/sysconfig/i18n r
/etc/profile.d rx
/etc/ld.so.cache rx
/dev h
/dev/tty rw
/dev/null w
/boot h
/bin x
/bin/bash3 x
/ h
-CAP_ALL
RES_FSIZE 54532 54532
RES_DATA 238320 238320
RES_STACK 25576 25576
RES_RSS 0 0
RES_NPROC 6 5
RES_NOFILE 260 260
RES_MEMLOCK 0 0
RES_AS 2982176 2982176
RES_LOCKS 0 0

connect {
disabled
}

bind {
disabled
}
}


**************************************************************************************************************************
as you can see clearly / is now hidden and /home is hidden /sbin is hidden as well why would i need my user to execute Administrative tasks ? right? I will give him only what he needs from sbin and acl already told mewhat he needs.

**************************************************************************************************************************

Demonstration of User ForEver Logging in

bash3-2.05a$ ls
nadine psybnc
bash3-2.05a$
bash3-2.05a$ cd /
bash3: cd: /: No such file or directory
bash3-2.05a$ cd /home
bash3: cd: /home: No such file or directory
bash3-2.05a$ cd /etc
bash3: cd: /etc: No such file or directory
bash3-2.05a$ cd /boot
bash3: cd: /boot: No such file or directory

AS you can see the user can go no where Besides his Home Directory ( few other dir's that you can assighn em as h if you want )
I hope this could lecture some one in chrooting maybe its not a chroot method but idont think the user has away to run outside his Home Directory.
I'll appreciate any comments given out to me here.
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby spender » Mon Nov 04, 2002 12:55 pm

that's not really a chroot, as all the user has to do to get out of your acl for /bin/bash3 is to execute something else, like /bin/sh. One way you could fix this, though I'm not sure if it'll work in every case, is to add i to every object where you allow execute. Then those programs will inherit the acl for /bin/bash3.

I would just rather put them in a real chroot. You can apply ACLs to stuff within a chroot just like you apply them to everything else...the ACL system handles them correctly.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Sharky » Mon Nov 04, 2002 3:17 pm

hey spender,
Well to be honest I dont know how to chroot users, and I'm not familiar with it.
All i know that pple i gave ACCCESS who have Decent Linux Experienec tehy could not run out of that jail.
If you can supply us with some chroot techniques or ACL then that would be much more appreciated from your side.
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby Sharky » Mon Nov 04, 2002 3:22 pm

Spender, One more comment I already forgot,
What do you think if this was added to the ACL :

/bin/bash2 h
/bin/bash h
/bin/sh h
/bin/ash h
/bin/bsh h
/bin/tcsh h
/bin/csh h
/bin/false h

Where all these are the shells Residing in /etc/shells
do you think the user will have any capability of breaking out? Theoratically? All I'm trying to do here is to make them locked in their $HOME
I would appreciate an experienced help of yours in this matter.
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby spender » Mon Nov 04, 2002 3:58 pm

There are many programs that they could use on the system to break out. Any interpreter, like perl, could be used. /lib/ld.so also allows them to break out. One thing they could not do however, is pass their own libraries to non-privileged applications (eg via LD_PRELOAD/LD_LIBRARY_PATH..etc) to break out, as grsecurity's mmap checking would stop that.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby spender » Mon Nov 04, 2002 4:04 pm

the suggestion I gave you about making it inherit the ACL for the shell on every execution would solve your problem. There's simply too many programs that allow system() usage that you would have to handle specially, and any program actually that they execute breaks out of that ACL you set up for /bin/bash3. Inheriting it is the only way to keep them in it.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Sharky » Mon Nov 04, 2002 7:55 pm

Spender, Your fast Reply was more than appreciated.
So you think if i replaced an "i" next to any object that has an "x" flag then that should inherit the original STATE of ACL thus eleminating many chances of breaking out of that jail.
That's what I just did in additional of hiding /bin/sh and other available Shells on my system, is there anything else a user can still use breakout in your opinion as a Net Admin ?
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby spender » Mon Nov 04, 2002 7:59 pm

they can't. Every time they fork or exec, that ACL will be carried with them, so they won't be able to break free from it. Current CVS if you didn't know already can trace processes to the IP that created them. The IP is automatically logged with every alert and audit in grsecurity. I think you'll find it useful for your multi-user server.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Sharky » Mon Nov 04, 2002 8:25 pm

Spender, I have to admit I'm really a great FAN of grsecurity.
One of my servers PRovide shells and we got fork bombed many times but I was able to eleminate that Via ulimit etc. one of my Boxes ALmost got rooted ( Redhat Box ), now before moving on from linux to OPenBsd for security issue's I thought I would give Linux a last Try by trying Grsecurity as I have to admit it really changed the whole behaviuor of my System with my reliability and improvements.
I will post on the FINAL ACL of the chroot in here (( after my learn mode adats)).
Thanks alot for your help you have been of great support.
Regards.
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby spender » Mon Nov 04, 2002 8:47 pm

OpenBSD only has non-executable stack for x86. PaX fully implements non-executable pages...that includes the stack, heap, bss, mmaps...etc. OpenBSD also doesn't have an ACL system. Systrace is basically just a wrapper, it's not a real MAC system. grsecurity allows you to run any software you want. OpenBSD can only claim you will be safe if you use only the default install (next to nothing), and even then, they don't have that great of a track record. Security problems will always exist, and therefore, relying on auditing alone is clearly not the correct solution. grsecurity aims to close entire classes of attacks instead of attack X against program Y. grsecurity's approach to security is one you won't find anywhere else, and I think people are beginning to realize what works (detection, prevention, containment), and what doesn't work (relying on claims that code is secure because it has been audited by imperfect humans). Of course, you will never find something like this in the commercial security industry, as it is driven by money and not really fixing any problems :)

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Sharky » Mon Nov 04, 2002 10:41 pm

well spender I tried to get the CVS but the CVS web is down because I'm already suffering a problem with running EGGDROP

Nov 5 02:36:13 Beirut kernel: grsec: attempt to load writable library [03:06:325811] by (eggdrop:23790) UID(512) EUID(512), parent (bash:23728) UID(512) EUID(512)
When u issue find -inum 325811 the path returned is /home/username/eggdrop/channels.so
as i read I beleive there's no way to override it onless with the O option that is only in the CVS version.
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby spender » Mon Nov 04, 2002 10:45 pm

what you'll probably want to do is make an ACL like:

/home O {
-CAP_ALL
}

so it will inherit the default ACL, ignore mmap and ptrace restrictions for their own binaries, and ensure that binaries executed in their home dirs can never get any root capabilities.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Sharky » Mon Nov 04, 2002 11:31 pm

I cant use the O option yet because i did not GET the CVS version, I tried the CVS website offered in grsecurity.net and it is not functioning.
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Postby spender » Mon Nov 04, 2002 11:34 pm

http://cvsweb.grsecurity.net/ isn't working? It works for me...

Just check out with the pserver

cvs -d:pserver:anonymous@grsecurity.net:/home/cvs login
enter "anonymous" as the password

cvs -d:pserver:anonymous@grsecurity.net:/home/cvs rdiff -u -r linux_2_4_19 -r HEAD grsecurity > ./grsecurity-cvs.patch
cvs -d:pserver:anonymous@grsecurity.net:/home/cvs co gradm

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Sharky » Mon Nov 04, 2002 11:37 pm

I was trying the wrong address, I'll try this one and keep u updated, thanks :)
Sharky
 
Posts: 43
Joined: Fri Nov 01, 2002 10:12 pm

Next

Return to RBAC policy development