* Random fork showing up in policy.
@ 2010-02-11 13:37 Daniel J Walsh
2010-02-12 13:07 ` Christopher J. PeBenito
0 siblings, 1 reply; 6+ messages in thread
From: Daniel J Walsh @ 2010-02-11 13:37 UTC (permalink / raw)
To: Stephen Smalley, SE Linux
[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]
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?
In the tmp dir I see this policy being compiled.
# grep process.*fork fork.tmp
class process { fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate };
type_transition initrc_t fork_exec_t:process fork_t;
type_transition init_t fork_exec_t:process fork_t;
type_transition unconfined_t fork_exec_t:process fork_t;
neverallow fork_t self:process fork;
But if I install.
# semodule -i fork.pp
libsepol.check_assertion_helper: neverallow violated by allow fork_t fork_t:process { fork };
libsemanage.semanage_expand_sandbox: Expand module failed
semodule: Failed!
If I remove the neverallow line.
# sesearch -A -s fork_t -p fork
Found 1 semantic av rules:
allow fork_t fork_t : process { fork sigchld } ;
Something strange is going on.
[-- Attachment #2: fork.tgz --]
[-- Type: application/x-compressed-tar, Size: 1461 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Random fork showing up in policy.
2010-02-11 13:37 Random fork showing up in policy Daniel J Walsh
@ 2010-02-12 13:07 ` Christopher J. PeBenito
2010-02-12 15:17 ` Daniel J Walsh
0 siblings, 1 reply; 6+ messages in thread
From: Christopher J. PeBenito @ 2010-02-12 13:07 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, SE Linux
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?
> In the tmp dir I see this policy being compiled.
>
> # grep process.*fork fork.tmp
> class process { fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate };
> type_transition initrc_t fork_exec_t:process fork_t;
> type_transition init_t fork_exec_t:process fork_t;
> type_transition unconfined_t fork_exec_t:process fork_t;
> neverallow fork_t self:process fork;
>
>
> But if I install.
>
> # semodule -i fork.pp
> libsepol.check_assertion_helper: neverallow violated by allow fork_t fork_t:process { fork };
> libsemanage.semanage_expand_sandbox: Expand module failed
> semodule: Failed!
>
> If I remove the neverallow line.
>
> # sesearch -A -s fork_t -p fork
> Found 1 semantic av rules:
> allow fork_t fork_t : process { fork sigchld } ;
>
> Something strange is going on.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Random fork showing up in policy.
2010-02-12 13:07 ` Christopher J. PeBenito
@ 2010-02-12 15:17 ` Daniel J Walsh
2010-02-12 16:01 ` {SPAM?} " Christopher J. PeBenito
0 siblings, 1 reply; 6+ messages in thread
From: Daniel J Walsh @ 2010-02-12 15:17 UTC (permalink / raw)
To: Christopher J. PeBenito; +Cc: Stephen Smalley, SE Linux
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?
>
>> In the tmp dir I see this policy being compiled.
>>
>> # grep process.*fork fork.tmp
>> class process { fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate };
>> type_transition initrc_t fork_exec_t:process fork_t;
>> type_transition init_t fork_exec_t:process fork_t;
>> type_transition unconfined_t fork_exec_t:process fork_t;
>> neverallow fork_t self:process fork;
>>
>>
>> But if I install.
>>
>> # semodule -i fork.pp
>> libsepol.check_assertion_helper: neverallow violated by allow fork_t fork_t:process { fork };
>> libsemanage.semanage_expand_sandbox: Expand module failed
>> semodule: Failed!
>>
>> If I remove the neverallow line.
>>
>> # sesearch -A -s fork_t -p fork
>> Found 1 semantic av rules:
>> allow fork_t fork_t : process { fork sigchld } ;
>>
>> Something strange is going on.
>
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.
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: {SPAM?} Re: Random fork showing up in policy.
2010-02-12 15:17 ` Daniel J Walsh
@ 2010-02-12 16:01 ` Christopher J. PeBenito
2010-02-12 21:31 ` Daniel J Walsh
0 siblings, 1 reply; 6+ messages in thread
From: Christopher J. PeBenito @ 2010-02-12 16:01 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, SE Linux
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.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: {SPAM?} Re: Random fork showing up in policy.
2010-02-12 16:01 ` {SPAM?} " Christopher J. PeBenito
@ 2010-02-12 21:31 ` Daniel J Walsh
2010-02-16 14:19 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Daniel J Walsh @ 2010-02-12 21:31 UTC (permalink / raw)
To: Christopher J. PeBenito; +Cc: Stephen Smalley, SE Linux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Random fork showing up in policy.
2010-02-12 21:31 ` Daniel J Walsh
@ 2010-02-16 14:19 ` Stephen Smalley
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2010-02-16 14:19 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Christopher J. PeBenito, SE Linux
On Fri, 2010-02-12 at 16:31 -0500, Daniel J Walsh wrote:
> 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.
FWIW, to deal with this same situation in the selinux testsuite, I
defined a test domain that did not have the domain attribute:
# Domain for process not allowed to fork.
# The same permissions as test_create_yes_t, except process fork
type test_create_no_t;
# In refpolicy, all types with "domain" attribute are allowed
# process_fork. Thus, to prevent test_create_no_t from picking up this
# permission so we can test it, we omit the domain attribute.
# Ideally, refpolicy would _not_ grant such permissions to every domain,
# as it makes the permission effectively unusable in real policy.
#domain_type(test_create_no_t)
unconfined_runs_test(test_create_no_t)
typeattribute test_create_no_t test_create_d;
allow test_create_no_t self:process ~fork;
--
Stephen Smalley
National Security Agency
--
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-02-16 14:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-11 13:37 Random fork showing up in policy Daniel J Walsh
2010-02-12 13:07 ` Christopher J. PeBenito
2010-02-12 15:17 ` Daniel J Walsh
2010-02-12 16:01 ` {SPAM?} " Christopher J. PeBenito
2010-02-12 21:31 ` Daniel J Walsh
2010-02-16 14:19 ` Stephen Smalley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.