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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.