[grsec] feature request / question / discussion / etc

[jnf]

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

I never meant to imply that it had anything to do with grsec itself.
And yes, but init/pid 1 not having CAP_SETPCAP means no one gets it, and
thus you can't fork and give a child any capabilities.

>
> Request capabilities ?

request/set/etc, whatever terminology you would like to use.


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

This however makes it difficult to just create a wrapper to the
service/program-- I mean you would have to fork, setuid, remove caps,
fork, remove more caps? Will capabilities even follow across a change of
user's like that?

> a) is by default with good reasons if you ask me.

But why, everyone waves their hands and states its a bad idea, and the
only real explanations I can find is an example of an sendmail exploit,
which as I understand it was the result of CAP_SETUID not CAP_PCAP, or
that the fs permission bits were never extended to follow the linux
standard.


>
> I consider RBAC and capabilities to be different things,

One extends the other.

> and thus somewhat
> unrelated.

unrelated in the sense that its not officially grsec's problem, but it
would be nice to see someone attempt to make better use of these
subsystems, otherwise you still end up with issues of having some users
that are more powerful than they really need to be.

Either that, or I missed something in my understanding of capabilities.

>
>
> regards,
>
>
> 	Igmar

regards,

jnf