CHROOTING local users sshd or *

[Sharky]

ls
grsecurity-1.9.7d-2.4.19.patch linux-2.4 linux-2.4.18-17.7.x linux-2.4.19.tar.gz
grsecurity-cvs.patch linux-2.4.18-10 linux-2.4.19 redhat

patch -p0 < grsecurity-cvs.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: grsecurity/Makefile
|diff -u grsecurity/Makefile:1.1.1.1 grsecurity/Makefile:1.1.1.2
|--- grsecurity/Makefile:1.1.1.1 Wed Aug 7 22:18:30 2002
|+++ grsecurity/Makefile Wed Aug 7 22:22:25 2002
--------------------------
File to patch:


any idea why is this returned/ maybe i have to rename linux-2.4.19 to some diff dir?

[spender]

you need to copy the patch into the linux source dir, and use patch -p1 and not -p0.

-Brad

[Sharky]

0ne more thing spender i got this patch now .
DO i apply it cleanly ? on a new source kernel ? or i can apply it above the other source that has grsecurity the old version applied? what i mean is I have my old linux directory that has the old patch, do i just apply this patch above the provious?

[spender]

you need to apply to a clean 2.4.19 kernel. There will be some failed hunks, but you can ignore them as they are just cvs header info.

-Brad

[Sharky]

on acleal src kernel 2.4.19 the CvS was applied, upon compilation time the following error was returned.



racl.c
gracl.c: In function `list_names':
gracl.c:322: structure has no member named `mode'
make[2]: *** [gracl.o] Error 1
make[2]: Leaving directory `/usr/src/linux/grsecurity'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory `/usr/src/linux/grsecurity'
make: *** [_dir_grsecurity] Error 2

the bzImage was not made.

[spender]

compile without the additional acl debugging enabled (actually if you're going to use the ACL system, I would recommend not using the debugging, as it produces enough logs to be annoying). I have a fix for the problem, but I have a queue of other things that are going to be committed, and it's not quite done yet.

-Brad

[Sharky]

Spender.
new Cvs kernel is up and running.
i upgraded gradm as well.
However SAME error is being yeild upon running an eggdrop desopite the the fact that "O" was placed next to the library object and the home directory as you EXPLAINED.
any ideas/thoughts?

[spender]

where is the eggrop binary located? The "O" capital O mode needs to be placed in the subject mode for the eggdrop binary. I am positive the code works. Perhaps you could paste your ACL?

-Brad

[Sharky]

Problem reached a final solution by relplacing an "O" next to the binary
I appreciate your help Spender and iwill be in touch in case i needed any further help, you have accomplished a nice task by turning linux to adevil and providing a Friendly Forum based Support.
My final ACL :

/home/Clever/eggdrop/eggdrop 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
}

}

[spender]

you also will want a lower-case o in the mode, since you don't want to inherit parent ACLs from the looks of it. the big O overrides the ptrace and mmap restrictions for a given binary, and the little o makes it so that ACL doesn't inherit ACLs from the parent ACLs.

-Brad

[Sharky]

d0ne thank you.
the thing I'm trying to accomplish and i am almost their actually is a user who has right to run apsybnc/EGGDrop in his home DIR and nothing Else, and thats what i have Almost accomplished with my FULL acl, maybe lots of acl's in one file but at least what i want is their right. ?
I was able for instance to have a user Locked in his home dir For instance
/home/username ---> he cant EXECUTE any code in his /home/username however he can execute /home/username/eggdrop/eggdrop binary and /home/username/psybnc/psybnc My only Concern was what if a user replaces a psybnc binary to a fork bomb naming it psybnc, I tried that my self and Fork bomb did not take any EFFECT for psybnc binary was limited for acertain cpu respose,fsize etc by the ACL. the only thing I would be worried about is replacing the psybnc binary or eggdrop with an exploit, in that CASE nothing i can do for no OS can protect against EXPLOITS remembering that I'm exposed to the public, However exploits chances are reduced by 88% for user is locked inside his Home dir.
thanks again

[spender]

if you use the inherited ACL, exploiting something on the system won't do them any good, as they'll still get the same ACL they had before, and they won't have any of root's capabilities. I don't think that ACL would allow them to execute any suid binaries either though...so you might want to make exceptions for them, and then give those binaries their own ACLs (preferably least privilege via the learning mode).

-Brad

[Sharky]

yep thats what i am douin
right now all my servers are in learning mode, EGGDROP/psybnc'/named/sshd all services, Once its finalized iwill paste my acl's here to get a final experience advice about any hole you might see here or there.
thanks in advance spender

[Sharky]

Hi again Spender.
That's my final ACL for locking users in their home DIR (( Assumed username is gr ))

/bin/bash3 o {
/var h
/var/tmp/a.swp w
/var/tmp rw
/var/spool/mail/gr
/var/run/utmp rw
/usr h
/usr/share/vim/vim61/syntax/syntax.vim r
/usr/share/vim/vim61/syntax/synload.vim r
/usr/share/vim/vim61/syntax/syncolor.vim r
/usr/share/vim/vim61/scripts.vim r
/usr/share/vim/vim61/plugin/rrhelper.vim r
/usr/share/vim/vim61/plugin/netrw.vim r
/usr/share/vim/vim61/plugin/gzip.vim r
/usr/share/vim/vim61/plugin/explorer.vim r
/usr/share/vim/vim61/plugin r
/usr/share/vim/vim61/macros/vimrc r
/usr/share/vim/vim61/filetype.vim r
/usr/share/terminfo/x/xterm r
/usr/share/terminfo/v/vt100 r
/usr/share/locale/locale.alias r
/usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES rxi
/usr/lib/locale/en_US/LC_MESSAGES r
/usr/lib/locale/en_US rxi
/usr/lib/libncurses.so.5.2 rxi
/usr/lib/libgpm.so.1.18.0 rxi
/usr/lib/gconv/gconv-modules.cache rxi
/usr/lib/gconv/ISO8859-1.so rxi
/usr/bin/uptime r
/usr/bin xi
/usr/X11R6/bin
/sbin h
/sbin/consoletype xi
/proc/6404/statm r
/proc/6404/stat r
/proc/6404/cmdline r
/proc/6331/statm r
/proc/6331/stat r
/proc/6331/cmdline r
/proc r
/lib rxi
/lib/ld-2.2.5.so xi
/lib/i686/libc-2.2.5.so rxi
/home h
/home/gr/a
/home/gr/.viminfo.tmp w
/home/gr/.viminfo w
/home/gr/.bashrc r
/home/gr/.bash_profile r
/home/gr/.bash_logout r
/home/gr/.bash_history ra
/home/gr/.a.swpx w
/home/gr/.a.swp w
/home/gr rw
/etc/sysconfig/i18n r
/etc/profile.d rxi
/etc/ld.so.cache rxi
/etc r
/dev/tty rw
/dev/null w
/dev h
/bin xi
/bin/bash3 xi
/ h
/bin/bash h # Available shells on my system Disabled
/bin/sh h
/bin/ash h
/bin/bsh h
/bin/tcs h
/bin/csh h
/bin/false h

+CAP_ALL

connect {
disabled
}

bind {
disabled
}

}


FEed me back with any comments !

[drago]

Hi sharky,
I'm shell provider like you, but the difference is that I'm still a beginner. Recently I've started using grsec because I really liked it. I saw the example that u have written in the forum but it is just for 1 user. If I have 10 users for example, do I need to write a separate acl for each one? I'll really appreciate any other information that you share with me. I've read quite a few docs about grsec but I guess from now on everytnig is practise.
10x in advance
Bye !!!