selinux January 2011 archive
Main Archive Page > Month Archives  > selinux archives
selinux: Re: SeLinux Policy design question

Re: SeLinux Policy design question

From: Ethan Heidrick <ethanheidrick_at_nospam>
Date: Wed Jan 26 2011 - 20:35:07 GMT
To: selinux@tycho.nsa.gov

hello Ger,

having a suite as you refer to as managing sys is a product inside the
array.
I may be misinformed but writing a policy that allows socketing for the
desired
services will allow for a better access measure for both the sys and the
user context

hope that helps,
en

On Wed, Jan 26, 2011 at 12:16 PM, Dominick Grift <domg472@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/26/2011 07:16 PM, Ger Lawlor (gelawlor) wrote:
> > Hi,
> >
> >
> >
> > I am pondering the best approach to design of appropriate filesystem
> > labeling that will reduce the long term complexity of managing contexts
> > and transitions in SeLinux.
> >
> > If I have a suite of services that interface within a single product and
> > those services have the potential to share access to similar sub
> > directory structures, but they
> >
> > currently only access files and execute within their own install
> > directories. It's obviously better to keep locked down any access
> > outside of each services domain.
> >
> > However, what if all services within a product were permitted open
> > access to all known directories within a product - apart from the
> > obvious i.e. these services could
> >
> > Interfere with each other, are there any reasons why this approach would
> > not be considered a suitable initial approach to seLinux development,
> > with continued
> >
> > Evolution, adding contexts for further refinement of control over time?
> > Are there best practice guides to filesystem labeling that considers the
> > complexity that can
> >
> > Come from excessive labeling?
>
> In my experience it is probably easier and safer to design policy as
> fine grained as you need to initially. Because it is in my experience
> easier to allow a restricted domain some extra permissions over time
> that it may need later than it is to restrict generic domain for a
> particular process.
>
> For example:
>
> Lets say you start as generic as possible and create a single domain
> where all the services in your suite runs in. That means that this
> single generic domain needs all permissions required to allow each
> service to function properly.
>
> Then later you decide to create a new domain for one of the services in
> your suite. That service requires a unique permission. That would then
> mean that your initial generic domain can drop that permission. Because
> the service that needs it now runs in its own domain with its own
> permission set.
>
> In theory if you know that the permission in question is unique then its
> easy to just remove that from the generic domain, however in practice it
> is not that easy to determine that it is unique and only required by a
> specific service.
>
> And so chances are that the initial generic domain becomes more
> permissive than it has to be.
>
> If this only applies to a single domain, then this is not such a big
> deal, because once you got to confining each other service in your suite
> over time, you could just revisit the initial more generic domain.
>
> But the more generic confined domains you have the harder it gets.
>
> It is in my view i guess a balance of priorities. I would probably keep
> my policy under development until i reached all my security goals, and
> then deploy it. But you may not have this luxury.
>
> You can choose you start with some generic domain to dump all your
> targeted processes in and refine policy later but basically you may end
> up with extra work, just to be able to basically deploy an unfinished
> policy.
>
> Besides in either case you run the risk of having to maintain policy
> over time any ways.
>
> But as for overall, keep it as generic as possible to reduce complexity,
> but not at the cost of not meeting your security goals.
> Because that's eventually what it is all about (meeting all your
> security goals.
>
> Disclaimer: I am not a professional security expert and so my
> suggestions may be fundamentally wrong. Use my advice at your own risk.
>
> >
> >
> > Thanks.
> >
> > Ger.
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1AgSsACgkQMlxVo39jgT8sPgCfTurKF2uof7bYDPG01Mwb+54X
> nNsAoLFJNtd/+NYh0NwwL8krb6iDmAqs
> =IuF6
> -----END PGP SIGNATURE-----
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.govwith
> the words "unsubscribe selinux" without quotes as the message.
>

-- 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.