[grsec] feature request / question / discussion / etc

[Igmar Palsenberg]

Hi,

> The biggest problems I faced were:
> 
> a) having to modify the kernel source myself as I learned that as least
> previously (I haven't checked in a while), that the capabilities system in
> linux is shipped in a disabled state- meaning that (this is going from
> memory of stuff done almost a year ago) that initd didn't have
> CAP_SETPCAP, and thus couldn't hand out capabilities, and as a result no
> process could give its children capabilities.

It has nothing to do with grsec and/or pax. CAP_SETPCAP is used to add / 
revoke capabilities of a process other than the one issuing the syscall. 
Processes still can remove / add capabilities themselves, but just not add 
/ remove them from other processes.

The capabilities system isn't disabled at all, only CAP_SETPCAP in the 
default set in pid 1, as it is considered a security risk.

> and
> 
> b) very few userspace applications actively request capabilities, I'd
> blame this mostly on (a) and problems like (a),

Request capabilities ? Processes should simply remove capabilities that 
they don't need. a) is by default with good reasons if you ask me.

> which I realize this is
> beyond the scope of any kernel development (to fix an entire userland),
> but perhaps it would be possible to check rbac policies, and see if an
> operation a process is trying to execute requires CAP_X, and if they are
> allowed to have CAP_X, let the operation suceed even though they didn't
> truly have the capability.

I consider RBAC and capabilities to be different things, and thus somewhat 
unrelated.



regards,


	Igmar