Re: {SPAM?} Re: Random fork showing up in policy.

[Daniel J Walsh <dwalsh@redhat.com>]

On 02/12/2010 11:01 AM, Christopher J. PeBenito wrote:
> On Fri, 2010-02-12 at 10:17 -0500, Daniel J Walsh wrote:
>> On 02/12/2010 08:07 AM, Christopher J. PeBenito wrote:
>>> On Thu, 2010-02-11 at 08:37 -0500, Daniel J Walsh wrote:
>>>> There has got to be something I am doing wrong.  But on my blog someone asked about writing a program that does a fork and having SELinux block it.  
>>>>
>>>> Where is the fork access coming from?
>>>
>>> Are you sure its not this:
>>>
>>> allow domain self:process { fork sigchld };
>>>
>>> in domain.te?
> [...]
>> Yes that is it.
>>
>> Seems like a strange rule to have on domain.  Might be better to move
>> it to daemon rather then have it on domain.
> 
> I don't agree.  When we started refpolicy, we added it to domain since
> its so pervasive.  Its also minimally security-relevant since the new
> process is in the same domain.
> 
> I went back to the old example policy, since that had the explicit fork
> permissions, and found that 228 of the 275 domains had the fork
> permission.  I saw plenty of non-daemon domains that can fork.
> 
> Basically, refpolicy took the convenience trade-off, and its taken
> almost 5 years for someone to take issue with this.  I'm still
> comfortable with this decision.
> 
The problem is it is very difficult to write policy without allowing fork.

I guess this is a case were we need the ability to remove a permission.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.