On 01/20/2017 06:14 PM, Steve Lawrence wrote: > On 01/20/2017 10:29 AM, Dominick Grift wrote: >> On 01/20/2017 04:16 PM, James Carter wrote: >>> On 01/19/2017 04:22 PM, Dominick Grift wrote: >>>> On 01/19/2017 06:21 PM, Stephen Smalley wrote: >>>>> On Wed, 2017-01-18 at 21:58 +0100, Dominick Grift wrote: >>>>>> On 01/18/2017 09:53 PM, James Carter wrote: >>>>>>> >>>>>>> Nicolas Iooss discovered that requiring a type in an optional block >>>>>>> after the type has already been declared in another optional block >>>>>>> results in a duplicate declaration error. >>>>>>> >>>>>> >>>>>> from what i have been told and from experience, types cannot, >>>>>> reliably, >>>>>> be declared in optional blocks. >>>>> >>>>> If true, that is likely a linker issue rather than a checkpolicy issue. >>>>> But that would make optionals rather useless if true. >>>> >>>> Let me present it in a different way then: >>>> >>>> Should one be able to, reliably, "blockinherit" in optionals? >>>> >>>> This is the commit in dssp1 where i hit the dead-end with declaring >>>> types in optionals: >>>> >>>> https://github.com/DefenSec/dssp-contrib/commit/45236da4030f0a541c26753e13a91f69411d022e >>>> >>>> >>>> I asked slawrence to have a look at the policy, and he indicated to me >>>> that blocks cannot be inherited in optionals. >>>> >>>> The compiler accepts it but the policy becomes inconsistent >>>> >>> >>> By inconsistent, do you mean that an the binary policy produced is not >>> valid, or something else? >> >> I used the word inconsistent because i actually forgot the details (it >> has been more than a year since I made this change and I tried hard to >> put this behind me, thinking that this was a fundamental limitation >> rather than a "bug"). >> >> I suspect the following: >> >> Rules end up in the policy but they aren't actually recognized/enforced. >> >> Either the above or: >> >> Rules do *not* end up in the policy even though they are specified. >> >> Maybe slawrence remembers what the issue exactly was (added to recipients) >> > > After digging through some past emails and discussions, I think part of > the issue is that things just start to get tricky and difficult to deal > with if you allow blockinherits (and for similar reasons blocks/macros) > in optionals. > > For example, say you had something like this: > > (optional foo > (block b > (blockinherit c) > ) > ... > ) > > (block d > (blockinherit b)) > > > If something in optional foo fails, then the entire block b goes away. > So does that mean the blockinherit b in block d goes away too? Or does > that stay? Removing it could be potentially tricky since we need to > remove tree nodes that have been copied (we don't currently where things > are copied to), and that removal might have side effects. This is a > similar reason why we don't allow macros in optionals. Once they've been > called, it becomes difficult to remove them if the macros go away. Not > impossible, but difficult. > > And since blockinherits can pull in blocks, you're essentially allowing > blocks inside optionals if you allow blockinherits inside optionals. So > this is likely the reason for not allowing blockinherits in optionals. > They can pull in blocks and macros, which aren't allowed to be optional. > > I agree that supporting optional blocks/macros/blockinherits/etc would > probably be really nice, but things get difficult pretty fast. > Re-resolve when optionals fail is a messy bit of code. Figuring out the > right thing to do and when isn't obvious or easy. > > Now, we could add in some restrictions that make the changes less > difficult (maybe), like blocks cannot be inside optionals, or > blockinherits inside optionals cannot inherit blocks that contain other > blocks. But again, that's still kindof a pain to implement and those are > probably restrictions that you'd end up running into eventually anyways. > So it would be best to just really figure out how to make it all work. > I'm sure it can work, it's just not an easy problem to solve and takes > time to figure out. > > - Steve > Thank you. I guess i somehow thought that the two issues were one and the same (ie. "corruption" when declaring types in optionals vs. "corruption" when inheriting blocks in optionals) Seems I was wrong there. The "type issue" is probably not CIL related and has been there for a very long time. The two issues have things in common though. Both declaring types in optionals, as well as inheriting blocks in optionals are unreliable and should be avoided. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
