CIL namespaces and blockinheritfilter keyword.

[Lukas Vrabec]

Hi All,

I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
wiki page [1] and I'm interested in CIL namespaces. I tried several
examples related to blockinheritence and all works just great!

However, in following example I see keyword "blockinheritfilter":

(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append write))))

(block myapp
(blockinherit logger)
(blockinheritfilter myapp logger
(allow process log (file (write)))))


If I understand it correctly, it should "remove" rule:
allow myapp.process log:file write;

So process type in myapp should have allowed:
allow myapp.process log:file {getattr append};

And process type in logger should have allowed:
allow logger.process log:file {getattr append write};

Which could be very cool feature, but I don't see any code in secilc
related to "blockinheritfilter". Are there any plans to implement also
this in CIL namespaces or is there any other way how to handle this
(DELETE statement is also not implemented) ?

Thanks for any help.
Lukas.


[1] https://github.com/SELinuxProject/cil/wiki

[Dominick Grift]

Post by Lukas Vrabec
Hi All,
I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
wiki page [1] and I'm interested in CIL namespaces. I tried several
examples related to blockinheritence and all works just great!
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append write))))
(block myapp
(blockinherit logger)
(blockinheritfilter myapp logger
(allow process log (file (write)))))

The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks.

loggers should not open the log file for write and so the main template should not include that permission in the first place:

(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))

Then if you have a misbehaving logger you can just append the bad rule to that block:

(block badlogger
(blockinherit logger)
(allow process log (file (write)))))

Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks
You probably would not be able to filter any of those.

Post by Lukas Vrabec
allow myapp.process log:file write;
allow myapp.process log:file {getattr append};
allow logger.process log:file {getattr append write};
Which could be very cool feature, but I don't see any code in secilc
related to "blockinheritfilter". Are there any plans to implement also
this in CIL namespaces or is there any other way how to handle this
(DELETE statement is also not implemented) ?
Thanks for any help.
Lukas.
[1] https://github.com/SELinuxProject/cil/wiki
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

[Dominick Grift]

Post by Dominick Grift

Post by Lukas Vrabec
Hi All,
I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
wiki page [1] and I'm interested in CIL namespaces. I tried several
examples related to blockinheritence and all works just great!
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append write))))
(block myapp
(blockinherit logger)
(blockinheritfilter myapp logger
(allow process log (file (write)))))

The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks.
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockinherit logger)
(allow process log (file (write)))))

Or even:

(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))

(block badlogger
(blockabstract badlogger)
(blockinherit logger)
(allow process log (file (write))))

(block yourlogger
(blockinherit badlogger))

Post by Dominick Grift
Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks
You probably would not be able to filter any of those.

Post by Lukas Vrabec
allow myapp.process log:file write;
allow myapp.process log:file {getattr append};
allow logger.process log:file {getattr append write};
Which could be very cool feature, but I don't see any code in secilc
related to "blockinheritfilter". Are there any plans to implement also
this in CIL namespaces or is there any other way how to handle this
(DELETE statement is also not implemented) ?
Thanks for any help.
Lukas.
[1] https://github.com/SELinuxProject/cil/wiki
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[Lukas Vrabec]

Post by Lukas Vrabec

Post by Dominick Grift

Post by Lukas Vrabec
Hi All,
I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
wiki page [1] and I'm interested in CIL namespaces. I tried several
examples related to blockinheritence and all works just great!
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append write))))
(block myapp
(blockinherit logger)
(blockinheritfilter myapp logger
(allow process log (file (write)))))

The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks.
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockinherit logger)
(allow process log (file (write)))))

(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockabstract badlogger)
(blockinherit logger)
(allow process log (file (write))))
(block yourlogger
(blockinherit badlogger))

Hi Dominick,

Yes, This is one of the options to create hierarchy when the block on
top will have just minimum rules and every child block will append new
rules.

Unfortunately, this probably won't work in real world. Let's say that I
have this hierarchy and badlogger block contains several allow rules and
I want to inherit all of them except one, *BUT* I'm not SELinux policy
expert and don't know how hierarchy looks like. That's the reason why
I'm looking for blockinheritfilter.

However, we should go via creating block namespaces hierarchy as you
described if there are no plans to implement this feature.

Thanks,
Lukas.

Post by Lukas Vrabec

Post by Dominick Grift
Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks
You probably would not be able to filter any of those.

Post by Lukas Vrabec
allow myapp.process log:file write;
allow myapp.process log:file {getattr append};
allow logger.process log:file {getattr append write};
Which could be very cool feature, but I don't see any code in secilc
related to "blockinheritfilter". Are there any plans to implement also
this in CIL namespaces or is there any other way how to handle this
(DELETE statement is also not implemented) ?
Thanks for any help.
Lukas.
[1] https://github.com/SELinuxProject/cil/wiki
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[Dominick Grift]

Post by Lukas Vrabec

Post by Lukas Vrabec

Post by Dominick Grift

Post by Lukas Vrabec
Hi All,
I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
wiki page [1] and I'm interested in CIL namespaces. I tried several
examples related to blockinheritence and all works just great!
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append write))))
(block myapp
(blockinherit logger)
(blockinheritfilter myapp logger
(allow process log (file (write)))))

The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks.
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockinherit logger)
(allow process log (file (write)))))

(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockabstract badlogger)
(blockinherit logger)
(allow process log (file (write))))
(block yourlogger
(blockinherit badlogger))

Hi Dominick,
Yes, This is one of the options to create hierarchy when the block on
top will have just minimum rules and every child block will append new
rules.
Unfortunately, this probably won't work in real world. Let's say that I
have this hierarchy and badlogger block contains several allow rules and
I want to inherit all of them except one, *BUT* I'm not SELinux policy
expert and don't know how hierarchy looks like. That's the reason why
I'm looking for blockinheritfilter.

I forgot the reason for dropping this functionality (I do recall me asking about this as well in the past but it seems that Google has no record of that) and so I will leave it to others to respond to this part of the question.

Post by Lukas Vrabec
However, we should go via creating block namespaces hierarchy as you
described if there are no plans to implement this feature.
Thanks,
Lukas.

Post by Lukas Vrabec

Post by Dominick Grift
Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks
You probably would not be able to filter any of those.

Post by Lukas Vrabec
allow myapp.process log:file write;
allow myapp.process log:file {getattr append};
allow logger.process log:file {getattr append write};
Which could be very cool feature, but I don't see any code in secilc
related to "blockinheritfilter". Are there any plans to implement also
this in CIL namespaces or is there any other way how to handle this
(DELETE statement is also not implemented) ?
Thanks for any help.
Lukas.
[1] https://github.com/SELinuxProject/cil/wiki
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

[jwcart2]

Post by Dominick Grift

Post by Lukas Vrabec

Post by Lukas Vrabec

Post by Dominick Grift

Post by Lukas Vrabec
Hi All,
I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
wiki page [1] and I'm interested in CIL namespaces. I tried several
examples related to blockinheritence and all works just great!
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append write))))
(block myapp
(blockinherit logger)
(blockinheritfilter myapp logger
(allow process log (file (write)))))

The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks.
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockinherit logger)
(allow process log (file (write)))))

(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append))))
(block badlogger
(blockabstract badlogger)
(blockinherit logger)
(allow process log (file (write))))
(block yourlogger
(blockinherit badlogger))

Hi Dominick,
Yes, This is one of the options to create hierarchy when the block on
top will have just minimum rules and every child block will append new
rules.
Unfortunately, this probably won't work in real world. Let's say that I
have this hierarchy and badlogger block contains several allow rules and
I want to inherit all of them except one, *BUT* I'm not SELinux policy
expert and don't know how hierarchy looks like. That's the reason why
I'm looking for blockinheritfilter.

I forgot the reason for dropping this functionality (I do recall me asking about this as well in the past but it seems that Google has no record of that) and so I will leave it to others to respond to this part of the question.

It was never implemented.

Inheritance is done in CIL by copying the inherited rules. This is not
complicated in the case where no rules are removed. A different approach would
be necessary to allow rules to be removed because we do not normally evaluate
things like attributes and attribute sets until after all of the copying is
done. We would have to evaluate as much of the policy as we could and then keep
cycling through all of the inheritance rules evaluating what we could with each
pass until we had evaluated all of the rules.

This is why we punted and decided to leave things like removing rules to a
higher-level language.

Post by Dominick Grift

Post by Lukas Vrabec
However, we should go via creating block namespaces hierarchy as you
described if there are no plans to implement this feature.

Sorry, but there are currently no plans to implement this feature.

Jim

Post by Dominick Grift

Post by Lukas Vrabec
Thanks,
Lukas.

Post by Lukas Vrabec

Post by Dominick Grift
Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks
You probably would not be able to filter any of those.

Post by Lukas Vrabec
allow myapp.process log:file write;
allow myapp.process log:file {getattr append};
allow logger.process log:file {getattr append write};
Which could be very cool feature, but I don't see any code in secilc
related to "blockinheritfilter". Are there any plans to implement also
this in CIL namespaces or is there any other way how to handle this
(DELETE statement is also not implemented) ?
Thanks for any help.
Lukas.
[1] https://github.com/SELinuxProject/cil/wiki
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

[Gary Tierney]

On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote:

... snip ...

Those wiki pages on SELinuxProject/cil are now pretty out of date
(you'll notice that some other statements mentioned there like
`template` are not implemented as well). The updated documentation is
at https://github.com/SELinuxProject/selinux/tree/master/secilc/docs.

Post by Lukas Vrabec
Hi Dominick,
Yes, This is one of the options to create hierarchy when the block on
top will have just minimum rules and every child block will append new
rules.
Unfortunately, this probably won't work in real world. Let's say that I
have this hierarchy and badlogger block contains several allow rules and
I want to inherit all of them except one, *BUT* I'm not SELinux policy
expert and don't know how hierarchy looks like. That's the reason why
I'm looking for blockinheritfilter.

I think it's more reasonable for someone not intimate with the policy to
familiarize themselves with the hierarchy/composition of a well structured
policy, rather than what they may need to disallow in a given scope (which may
come from other inherited blocks, calls to macros, or `in` statements scattered
across several policy modules). This means they can compose their policy out
of high level building blocks rather than low level allow rules (which arguably
would require a policy expert to fully understand the implications of).

"blockinheritfilter" also seems to be at odds with the permission
whitelisting/deny-by-default model of SELinux by having the policy author
revoke permissions rather than permit them.

Thanks,
Gary.

Post by Lukas Vrabec
However, we should go via creating block namespaces hierarchy as you
described if there are no plans to implement this feature.
Thanks,
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.

[Lukas Vrabec]

Post by Gary Tierney
... snip ...
Those wiki pages on SELinuxProject/cil are now pretty out of date
(you'll notice that some other statements mentioned there like
`template` are not implemented as well).  The updated documentation is
at https://github.com/SELinuxProject/selinux/tree/master/secilc/docs.

Post by Lukas Vrabec
Hi Dominick,
Yes, This is one of the options to create hierarchy when the block on
top will have just minimum rules and every child block will append new
rules.
Unfortunately, this probably won't work in real world. Let's say that I
have this hierarchy and badlogger block contains several allow rules and
I want to inherit all of them except one, *BUT* I'm not SELinux policy
expert and don't know how hierarchy looks like. That's the reason why
I'm looking for blockinheritfilter.

I think it's more reasonable for someone not intimate with the policy to
familiarize themselves with the hierarchy/composition of a well structured
policy, rather than what they may need to disallow in a given scope (which may
come from other inherited blocks, calls to macros, or `in` statements scattered
across several policy modules).  This means they can compose their
policy out
of high level building blocks rather than low level allow rules (which arguably
would require a policy expert to fully understand the implications of).
"blockinheritfilter" also seems to be at odds with the permission
whitelisting/deny-by-default model of SELinux by having the policy author
revoke permissions rather than permit them.

Understand.

Thank you for clarification.

Lukas.

Post by Gary Tierney
Thanks,
Gary.

Post by Lukas Vrabec
However, we should go via creating block namespaces hierarchy as you
described if there are no plans to implement this feature.
Thanks,
Lukas.
-- 
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.