[Apparmor-dev] Confining the "kill" capability?

[John Johansen]

On Tue, Nov 27, 2007 at 10:18:19AM +0200, Markku Savela wrote:
> The capability check for CAP_KILL is only checked when a process
> attempts to kill a process belonging to another user (the LSM hook is
> not even called otherwise). [or perhaps this only special effect of
> root user, I have not analyzed the code too closely yet]
> 
> I was xperimenting with idea: can AppArmor contain a root shell? So I
> just made a profile for "tcsh", with following lines
> 
>      /** mixr,
>      /root/ rw,
>      /root/** rw,
> 
> as far as file system is concerned, above works very nice, but
> containment "fails" in major way with "kill" -- the shell can kill all
> root owned processes.
> 
> The "fails" in quotes, because I assume that it works as
> intended. However, it would be nice to be able to prevent a process
> killing other processes, even if they are run under same user (I would
> not like a bug in firefox cause some malware to be able to kill all of
> my other processes).
> 
I don't know that it is what is intended but what has been done, in the
past, it will change.

> AppArmor does not currently implement the hook "task_kill". A quick
> fix would be just to add this and check for CAP_KILL. This would of
> course be a slight change in CAP_KILL capability semantics, when
> AppArmor is running (instead of being capability to kill any process
> of any user, it would be a required capability to kill any other
> process, except self).
> 
> Another approach would require extending the profile syntax with some
> construct that indicates capability to kill other processes of the
> same user.
> 
yes this is being done, I just need to go back and cleanup the patch
and get it out, it has been part of the ipc patches but can come before
the other ipc patches are finished.

signals between tasks will be allowed if they are in the same profile,
but will require signal privledge to another task if in a different
profile.

there are two competing syntaxes at the moment either, just using signal
directly or layering on ipc.

case 1:

/foo {
   signal kill -> /bar,   #allow tasks confined by /foo to send kill to
                          #tasks confined by /bar
}


case 2:
/foo {
   ipc rw -> /bar,	#allow tasks confined by /foo to do any kind of
                        #ipc including send signals to tasks confined by
                        # /bar
}

/foo2 {
   ipc signal (kill) -> /bar,	#allow only signal SIG_KILL as ipc to tasks
				#confined with /bar
}


I have been leaning towards case 1 syntax as signals don't really fit in
to the read, write syntax of the other forms of ipc.  But the actual
decision of how to go was going to be decided by the mailing list.

thanks
john
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20071127/88af21f0/attachment.pgp