Page 1 of 1
kernel-2.4.20 gradm Errors ( Fresh compile )
Posted:
Sat Feb 08, 2003 6:56 pm
by Sharky
Hi Spender.
Sorry for bothering you with my problems.
Same old box we secured before, I upgraded from kernel 2.4.19 to 2.4.20
then applied grsecurity on it the new version.
i installed the new version of gradm as well 1.6
it seems i am facing this problem every time i gradm -E
[root@ipchains grsecurity]# gradm -E
Error writing to /proc/sys/kernel/grsecurity/acl
write: Invalid argument
any idea thoughts?
Posted:
Sat Feb 08, 2003 9:05 pm
by spender
You have to use the gradm that comes with the version of grsecurity on the site. So for grsec 1.9.8, you have to use gradm 1.6. For grsec 1.9.9, you have to use gradm 1.7.
-Brad
Posted:
Sun Feb 09, 2003 2:09 am
by Sharky
Case Solved and closed.
thank you spender as usual
By the way I'm now into novell, I'm taking few courses in my school and i have noticed many features of your Grsecurity are there in novell, the only thing you miss is the effective rights object Filters... i'm not sure if you are familiar with that.
I'm doin a detailed research with examples about grsecurity to show it to my proffessor.
Posted:
Sun Feb 09, 2003 2:51 am
by Sharky
spender i founda whole or maybe it's not that serious even.,
say a user is in an untrusted GID 6677 on my system
he cant execute shit .
he tries to craete executable file "a"
as clearly seen if he types ./a
it will return permission denied.
however if he uses sh a
or csh a
or any other available shells he can override his rights an execute the file!
thuse breaking trusted path execution.
Can you shed some lights in here?
Posted:
Sun Feb 09, 2003 11:04 am
by spender
That's the problem with TPE. While they couldn't execute an elf binary in their homedir, there's nothing stopping them from loading a script with bash from their homedir. It's handled just as if they had typed all the commands into the interpreter themselves. There's nothing really you can do to stop this other than only having restricted interpreters on your system.
-Brad
Posted:
Sun Feb 09, 2003 11:53 am
by Sharky
so the only way to stop em would be denying them using other shells rather their own ey? or creating a restricted shell by ACL's like the one we did bfore ( bash3) to lock em in their home dir.
and hide all /etc/shells