-----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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
