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