Knowing policy contents

[Maciej Lasyk]

On Mon, Feb 24, 2014 at 06:37:38PM +0100, Dominick Grift wrote:
> On Mon, 2014-02-24 at 16:50 +0100, Maciej Lasyk wrote:
> 
> <snip>
> 
> > > >>> 
> > > >>> Let's say that I have file 
> > > >>> /etc/selinux/targeted/modules/active/modules/lvm.pp
> > > >>> 
> > > >>> What would be the easiest way to view the policy that this file 
> > > >>> contains? 
> > > >>> 
> > > >>> But how could I know how the policy looks like for already created and 
> > > >>> loaded policies? Let's stick to that lvm.pp as the example.
> > > >>>
> 
> <snip>
> 
> >  
> > > Usually sesearch is a better solution then just looking at the source.  The
> > > source is just going to show you the interfaces called, where is sesearch will
> > > show you the results.
> > > 
> > > sesearch -A -s lvm_t
> > > 
> > > Will show you every allow rule that effects the lvm_t process domain.
> > 
> > Great - thanks - that really did the job :)
> 
> Glad to hear that it helped you get the job done but for the record:
> 
> Although the answer that dwalsh gave is one hundred percent correct. It
> is not the answer to your initial question. 
> 
> You do no not know that lvm_t is declared in lvm.pp. Sure in this case
> the type is consistent with module name but that is not always the case.
> Also who's to say that there aren't any other types declared in this
> module (spoiler: there are)?
> 
> Not to mention that a typical .pp policy package also encloses a .fc
> file context file.
> 
> semodule_unpackage should, in my view, just be fixed to deal with this
> checksum issue. Also i believe that currently semodule_unpackage tool
> cannot properly extract the enclosed (.fc) file context file.
> 
> These are, in my view, actually a couple of bugs that would improve
> usability a lot when fixed. Some how it does not get the attention it
> deserves.

Hmm I couldn't agree more. Honestly after you gave me guys URL to the
SELinux repo @Fedora than I grepped for that I looked for and found
exactly what you just wrote (that there might be inconsistencies in
module names or there might be other types declarations in modules). So
thanks for this explanation - I will keep that in mind while using Dan's
method.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20140224/bea63a91/attachment.sig>