secilc: in statement ordering limitations

secilc: in statement ordering limitations

[Dominick Grift]

I got a little carried away with block and in statements (to say the
least)

I hit a limitation were ordering of modules matters (e.g. ordering of
entries in LISTING or entries fed into secilc)

I order my modules in alphabetical order so for example
policy/modules/systemd/systemd.cil comes after
policy/modules/system/dbus for example.

If i, in the dbus.cil file now want to insert some declarations in a
systemd block i hit issues due to that ordering issue

If i move the systemd.cil up the stack then i can work around the
ordering issue but it is a dead-end. Ordering issues suck (/me points to
sidorder statement)

Re: secilc: in statement ordering limitations

[James Carter]

On 05/21/2014 12:30 PM, Dominick Grift wrote:
> I got a little carried away with block and in statements (to say the
> least)
>
> I hit a limitation were ordering of modules matters (e.g. ordering of
> entries in LISTING or entries fed into secilc)
>
> I order my modules in alphabetical order so for example
> policy/modules/systemd/systemd.cil comes after
> policy/modules/system/dbus for example.
>
> If i, in the dbus.cil file now want to insert some declarations in a
> systemd block i hit issues due to that ordering issue
>
> If i move the systemd.cil up the stack then i can work around the
> ordering issue but it is a dead-end. Ordering issues suck (/me points to
> sidorder statement)
>
>

Thanks for the report. All ordering issues are bugs.

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: secilc: in statement ordering limitations

[James Carter]

On 05/21/2014 12:30 PM, Dominick Grift wrote:
> I got a little carried away with block and in statements (to say the
> least)
>
> I hit a limitation were ordering of modules matters (e.g. ordering of
> entries in LISTING or entries fed into secilc)
>
> I order my modules in alphabetical order so for example
> policy/modules/systemd/systemd.cil comes after
> policy/modules/system/dbus for example.
>
> If i, in the dbus.cil file now want to insert some declarations in a
> systemd block i hit issues due to that ordering issue
>

I am having problems reproducing the problem.

In one file, I have:

(block bb
	(type t1)
	(type t2)
	(boolean b1 false)
	(tunable tun1 true)
	(macro m ((boolean b))
		(tunableif tun1
			(true
				(allow t1 t2 (policy.file (write))))
			(false
				(allow t1 t2 (policy.file (execute)))))
		(booleanif b
			(true
				(allow t1 t2 (policy.file (read))))))

	(call m (b1))
)

and in another, I have:

(in bb
	(tunableif bb.tun1
		(true
			(allow t2 t1 (policy.file (read write execute)))))
	(type t3))

The order that I send the files to secilc doesn't seem to matter.

Could you give me a little bit more information on what you are doing?

Thanks,
Jim

> If i move the systemd.cil up the stack then i can work around the
> ordering issue but it is a dead-end. Ordering issues suck (/me points to
> sidorder statement)
>
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: secilc: in statement ordering limitations

[Dominick Grift]

On Fri, 2014-05-23 at 09:15 -0400, James Carter wrote:

> Could you give me a little bit more information on what you are doing?

Strange.. It is kind of hard for me to put it any other way.

I have a short 5 minute video that demo's the issue:

https://www.youtube.com/watch?v=hU_yVZJpAyM

If you are not able to view the demo then i guess i will have to find
another way to explain it

Re: secilc: in statement ordering limitations

[Dominick Grift]

On Fri, 2014-05-23 at 16:32 +0200, Dominick Grift wrote:
> On Fri, 2014-05-23 at 09:15 -0400, James Carter wrote:
> 
> > Could you give me a little bit more information on what you are doing?
> 
> Strange.. It is kind of hard for me to put it any other way.

The core, i suspect, is that in my case systemd depends on a namespace
in dbus ( file.etc.dbusd.systemd.obj ) and dbus depends on a namespace
in systemd (file.unit.systemd.dbusd.obj)

Re: secilc: in statement ordering limitations

[Steve Lawrence]

On 05/23/2014 10:32 AM, Dominick Grift wrote:
> On Fri, 2014-05-23 at 09:15 -0400, James Carter wrote:
> 
>> Could you give me a little bit more information on what you are doing?
> 
> Strange.. It is kind of hard for me to put it any other way.
> 
> I have a short 5 minute video that demo's the issue:
> 
> https://www.youtube.com/watch?v=hU_yVZJpAyM
> 
> If you are not able to view the demo then i guess i will have to find
> another way to explain it
> 

I think this is an example of the core problem:

  (in foo.bar
    (type x))

  (in foo
    (block bar))

  (block foo)

So, an in-statement is inserting into a block that is created by another
in-statement, so there's an order dependence.

- Steve

Re: secilc: in statement ordering limitations

[James Carter]

On 05/23/2014 11:04 AM, Steve Lawrence wrote:
> On 05/23/2014 10:32 AM, Dominick Grift wrote:
>> On Fri, 2014-05-23 at 09:15 -0400, James Carter wrote:
>>
>>> Could you give me a little bit more information on what you are doing?
>>
>> Strange.. It is kind of hard for me to put it any other way.
>>
>> I have a short 5 minute video that demo's the issue:
>>
>> https://www.youtube.com/watch?v=hU_yVZJpAyM
>>
>> If you are not able to view the demo then i guess i will have to find
>> another way to explain it
>>
>
> I think this is an example of the core problem:
>
>    (in foo.bar
>      (type x))
>
>    (in foo
>      (block bar))
>
>    (block foo)
>
> So, an in-statement is inserting into a block that is created by another
> in-statement, so there's an order dependence.
>

So to fix this we need to split up the processing for "in", so that blocks and 
macros are processed first?

Jim

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency