smaller memory footprint for 'strict' policy - helping gentoo as well

smaller memory footprint for 'strict' policy - helping gentoo as well

[Luke Kenneth Casson Leighton]

following on from me blithering on about gentoo, and tying
in valdis' questions about smaller "strict" memory footprints
[gods, i had no idea: i was going to recommend a strict selinux
policy for 128mb machines let alone 256!], what is the way forward?

valdis raised the question: does the new binary module system minimise
the amount of memory used?

does that _actually_ help out wrt complexity of the selinux policy
_source_ (probably not).

hm, to avoid confusion - the requirements:

* to minimise memory usage at runtime

* to keep the number of source code files and size of source code
  files to _absolute_ minimum (if done properly should cover 1st
  requirement as well).

* to still make it possible to have redhat-loved run-time "modules"
  including having their associated runtime booleans.

* to still understand what's going on :)

... would the concept of a macros/unused directory help out, here?
along with a list of the macros you removed (and the files
they're in), valdis - and why.  and chris, also?

... surely... there's some analysis done by the m4 macro
compiler that automatically removes "unwanted" / "unused"
macros?

could that be done as a separate pre-pass / analysis step,
making it unnecessary to consider a macros/unused directory?

any further thoughts, anyone?

l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: smaller memory footprint for 'strict' policy - helping gentoo as well

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>following on from me blithering on about gentoo, and tying
>in valdis' questions about smaller "strict" memory footprints
>[gods, i had no idea: i was going to recommend a strict selinux
>policy for 128mb machines let alone 256!], what is the way forward?
>
>valdis raised the question: does the new binary module system minimise
>the amount of memory used?
>  
>
yes and no. The loadable (we changed the name since binary == 
proprietary to many Linux users) module system by itself will not change 
anything kernel-side. That is, if you used the module compiler and built 
the current policy you would (should anyway ;P ) get an identical kernel 
policy. However, the module system does allow Red Hat and others that 
don't want to distribute policy source the ability to add and remove 
parts of the policy in production. This translates to less kernel policy 
and thus less memory usage if used appropriately.

>does that _actually_ help out wrt complexity of the selinux policy
>_source_ (probably not).
>
>  
>
no but the reference policies from Tresys will :)

>hm, to avoid confusion - the requirements:
>
>* to minimise memory usage at runtime
>
>  
>
>* to keep the number of source code files and size of source code
>  files to _absolute_ minimum (if done properly should cover 1st
>  requirement as well).
>
>  
>
Not sure why this is a requirement other than clarity, which small size 
does not necessarilly give you. The goal is a smaller kernel policy, all 
the stuff before that is development.

>* to still make it possible to have redhat-loved run-time "modules"
>  including having their associated runtime booleans.
>
>  
>
None of the policy features have changed, Red Hat will choose which 
options to continue as runtime booleans and which (if any) to move to 
the new link time optionals.

>* to still understand what's going on :)
>
>  
>
reference policies should make what is actually happening in policy 
*much* more clear 

>... would the concept of a macros/unused directory help out, here?
>along with a list of the macros you removed (and the files
>they're in), valdis - and why.  and chris, also?
>
>  
>
>... surely... there's some analysis done by the m4 macro
>compiler that automatically removes "unwanted" / "unused"
>macros?
>
>could that be done as a separate pre-pass / analysis step,
>making it unnecessary to consider a macros/unused directory?
>
>  
>
Why? if the macro is unused it never makes it past the policy.conf which 
you shouldn't be reading directly anyway, aside from debugging.

>any further thoughts, anyone?
>
>  
>
The main reason for the gigantic policy that nearly everyone loads is 
lack of policy management infrastructure which we are trying to address 
now. The modules are the first step toward this, more work later on will 
make the policy management far more robust.

Even before the module work you could always grab the sf.net cvs policy 
and disable all the modules you didn't want. It was possible to create a 
very small (= 20k rules) _usable_ policy from that, if you didn't need 
all the extra application policies.

Joshua

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: smaller memory footprint for 'strict' policy - helping gentoo as well

[Luke Kenneth Casson Leighton]

On Mon, May 30, 2005 at 10:37:17PM -0400, Joshua Brindle wrote:

> >... surely... there's some analysis done by the m4 macro
> >compiler that automatically removes "unwanted" / "unused"
> >macros?
> >
> >could that be done as a separate pre-pass / analysis step,
> >making it unnecessary to consider a macros/unused directory?
> >
> > 
> >
> Why? if the macro is unused it never makes it past the policy.conf which 
> you shouldn't be reading directly anyway, aside from debugging.
 
 okay - then i must have misunderstood what valdis has done that
 reduces the memory footprint so dramatically.

 i mean, _yes_ of course, personally, i remove any policy
 domains that aren't used, i assume that naturally _everybody_
 does that because otherwise a package could be installed
 without consent and it would work (whereas if the policy
 isn't there, it will definitely fail).

 i am confused.

 valdis, hi, any chance you could elaborate?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: smaller memory footprint for 'strict' policy - helping gentoo as well

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On Tue, 31 May 2005 12:09:48 BST, Luke Kenneth Casson Leighton said:

>  okay - then i must have misunderstood what valdis has done that
>  reduces the memory footprint so dramatically.
> 
>  i mean, _yes_ of course, personally, i remove any policy
>  domains that aren't used, i assume that naturally _everybody_
>  does that because otherwise a package could be installed
>  without consent and it would work (whereas if the policy
>  isn't there, it will definitely fail).

The only thing that I really did was get very fascist about moving stuff to
unused/, (I have more things in unused/ than not) and identify a few things in
macros/program that need some work (I think I identified like 10 entire files
in there that *my* config totally doesn't need).  I suspect the reason I saw
such big savings is because some of the stuff in macros/program generates a
*lot* of $USER_foo_t types unnecessarily (thus the need for more ifdefs to
suppress that).

I'll make up a proper patch later this week when I have more time...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: smaller memory footprint for 'strict' policy - helping gentoo as well

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 10:10:40AM -0400, Valdis.Kletnieks@vt.edu wrote:

> in there that *my* config totally doesn't need).  I suspect the reason I saw
> such big savings is because some of the stuff in macros/program generates a
> *lot* of $USER_foo_t types unnecessarily (thus the need for more ifdefs to
> suppress that).
> 
> I'll make up a proper patch later this week when I have more time...

 GREAT! the less, the merrier :)



-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: smaller memory footprint for 'strict' policy - helping gentoo as well

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Tue, 31 May 2005 02:28:24 BST, Luke Kenneth Casson Leighton said:

> ... would the concept of a macros/unused directory help out, here?
> along with a list of the macros you removed (and the files
> they're in), valdis - and why.  and chris, also?

Almost all the gains I got were basically from moving stuff from
domains/programs/foo.te to domains/programs/unused/foo.te

> ... surely... there's some analysis done by the m4 macro
> compiler that automatically removes "unwanted" / "unused"
> macros?

The remaining gotcha is that some of the stuff in macros/program/foo_macros.te
could use some better ifdef wrapping, which I haven't looked into yet.

> could that be done as a separate pre-pass / analysis step,
> making it unnecessary to consider a macros/unused directory?

The current 'ifdef(foo.te)' keying off the presence of a foo.te in
domains/programs is a good and clear way to manage it.  Want a given
program's policy? Move it to domains/program.  Want to get rid of it?
Move to domains/program/unused.  Simple, clear, and not much of a maint
headache.

We just need to do some more ifdef'ing to make the resulting policy more
optimal.  There's no need for a macros/unused directory.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: smaller memory footprint for 'strict' policy - helping gentoo as well

[Luke Kenneth Casson Leighton]

On Tue, May 31, 2005 at 09:53:12AM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 31 May 2005 02:28:24 BST, Luke Kenneth Casson Leighton said:
> 
> > ... would the concept of a macros/unused directory help out, here?
> > along with a list of the macros you removed (and the files
> > they're in), valdis - and why.  and chris, also?
> 
> Almost all the gains I got were basically from moving stuff from
> domains/programs/foo.te to domains/programs/unused/foo.te
> 
> > ... surely... there's some analysis done by the m4 macro
> > compiler that automatically removes "unwanted" / "unused"
> > macros?
> 
> The remaining gotcha is that some of the stuff in macros/program/foo_macros.te
> could use some better ifdef wrapping, which I haven't looked into yet.
 
 someone (stephen?) mentioned that policy.conf doesn't end up with stuff
 that isn't actually required.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.