hidden kernel process visible

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

hidden kernel process visible

Postby glaeken » Tue Mar 08, 2005 5:27 pm

CONFIG_GRKERNSEC_ACL_HIDEKERN=y

# gradm -E
The operation you requested cannot be performed because the RBAC system is currently enabled.

Code: Select all
root         2  0.0  0.0     0    0 ?        SWN  20:55   0:00 [ksoftirqd/0]
root         3  0.0  0.0     0    0 ?        SW<  20:55   0:00 [events/0]
root         4  0.0  0.0     0    0 ?        SW<  20:55   0:00 [khelper]
root         9  0.0  0.0     0    0 ?        SW<  20:55   0:00 [kthread]
root        17  0.0  0.0     0    0 ?        SW<  20:55   0:00 [kblockd/0]
root        62  0.0  0.0     0    0 ?        SW   20:55   0:01 [pdflush]
[...]

I can see kernel processes
Code: Select all
stat64("/proc/2", {st_mode=S_IFDIR|0550, st_size=0, ...}) = 0
open("/proc/2/stat", O_RDONLY)          = 7
read(7, "2 (ksoftirqd/0) S 1 0 0 0 -1 410"..., 1023) = 122


kern2.6.11 grsec2.1.3
Nothing changed in policy file (I noticed this when I recompiled kernel and changed grsec 2.1.2 on 2.1.3)

One more thing...
if there is a subject in a RBAC system, even empty, like this one:
Code: Select all
subject /root dX {

}

then I cant strace subject's processes, whatever flags are given:
Code: Select all
# strace ./tc
execve("./tc", ["./tc"], [/* 27 vars */]) = 0
strace: exec: Permission denied

I tried flasg t and O but I still can't do strace.
but when I remove it:
Code: Select all
#subject /root dX {
#
#}

I can do strace:
Code: Select all
[22:22:50] root@dsl:~# strace ./tc
execve("./tc", ["./tc"], [/* 27 vars */]) = 0
uname({sys="Linux", node="dsl", ...})   = 0
[...]


It's reasonable, but is this a correct behavior?
Last edited by glaeken on Tue Mar 08, 2005 6:24 pm, edited 1 time in total.
glaeken
 
Posts: 15
Joined: Sun Feb 20, 2005 9:53 am

Postby glaeken » Tue Mar 08, 2005 5:43 pm

ptrace can be done from any account, i.e. normal user can strace /bin/bash, even if there is -CAP_SYS_PTRACE in main ACL "/"
glaeken
 
Posts: 15
Joined: Sun Feb 20, 2005 9:53 am

Postby spender » Fri Mar 11, 2005 4:50 pm

CAP_SYS_PTRACE doesn't have anything to do with the ability to ptrace. It only decides whether a task can ptrace tasks with other uids. When you added the "t" flag, did you add it to the subject belonging to the process that was attempting to ptrace the task, or did you add it to the subject of the task you were trying to ptrace? The first is correct, while the second is incorrect.

As for the kernel processes being viewable, I've fixed the problem in CVS.

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


Return to grsecurity support