Re: CIL namespaces and blockinheritfilter keyword.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote:
> On 04/09/2018 10:41 AM, Dominick Grift wrote:
> > On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote:
> >> On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote:
> >>> 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)))))
> >>>
> >>
> >> 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)))))
> > 
> > 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))
> > 
> 
> 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.

> 
> However, we should go via creating block namespaces hierarchy as you
> described if there are no plans to implement this feature.
> 
> Thanks,
> Lukas.
> 
> >>
> >> 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.
> >>
> >>
> >>>
> >>> 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
> >>>
> >>> -- 
> >>> 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.
> 




-- 
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: PGP signature


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux