grsecurity forums

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
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.

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

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.

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.

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

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

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

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

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.

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

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.

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

I was trying the wrong address, I'll try this one and keep u updated, thanks