SElinux and databases

I'm working on writing an SElinux policy for foreman and the proxy, both of which are nearly done. One of the final decisions that needs to be made, though, is how to handle different database backends. From my perspective there are really two ways to handle allowing connections to user's choice of database:

  1. Include support for all three (pg, mysql, sqlite) databases in the foreman core selinux policy. This has the disadvantage of making the basic policy files more complex and could be a minor security risk because of unnecessary access, but it means that one policy (and subsequent package) meets the needs of all users.
  2. Create separate policies for each database and package them individually (i.e. foreman-selinux-postgresql). This just adds a lot of maintenance overhead and means that users have to install yet another package. It also makes locking foreman down via SElinux beyond allowing it to run unconfined will be more complex in the future.

I'm leaning pretty heavily toward the first option, but want to know how others feel about this. Is potentially allowing access to a database other than the one being used by Foreman a policy decision we are okay with to reduce potential packaging and maintenance issues?

-Sam

I'd probably ask this question on -users. -Brian

··· On Tue, Feb 26, 2013 at 10:35 AM, Sam Kottler wrote: > I'm working on writing an SElinux policy for foreman and the proxy, both of which are nearly done. One of the final decisions that needs to be made, though, is how to handle different database backends. From my perspective there are really two ways to handle allowing connections to user's choice of database: > > 1. Include support for all three (pg, mysql, sqlite) databases in the foreman core selinux policy. This has the disadvantage of making the basic policy files more complex and *could* be a minor security risk because of unnecessary access, but it means that one policy (and subsequent package) meets the needs of all users. > 2. Create separate policies for each database and package them individually (i.e. foreman-selinux-postgresql). This just adds a lot of maintenance overhead and means that users have to install yet another package. It also makes locking foreman down via SElinux beyond allowing it to run unconfined will be more complex in the future. > > I'm leaning pretty heavily toward the first option, but want to know how others feel about this. Is potentially allowing access to a database other than the one being used by Foreman a policy decision we are okay with to reduce potential packaging and maintenance issues? > > -Sam > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >

> I'm working on writing an SElinux policy for foreman and the proxy, both of which are nearly done. One of the final decisions that needs to be made, though, is how to handle different database backends. From my perspective there are really two ways to handle allowing connections to user's choice of database:
>
> 1. Include support for all three (pg, mysql, sqlite) databases in the foreman core selinux policy. This has the disadvantage of making the basic policy files more complex and could be a minor security risk because of unnecessary access, but it means that one policy (and subsequent package) meets the needs of all users.

Could they be included, but wrapped in booleans?

Then maybe it's ok to disable PostgreSQL and MySQL booleans by default,
and then we can enable them from the installer (when it gets other DB
support) or maybe even in the foreman-${database} packages?

> 2. Create separate policies for each database and package them individually (i.e. foreman-selinux-postgresql). This just adds a lot of maintenance overhead and means that users have to install yet another package. It also makes locking foreman down via SElinux beyond allowing it to run unconfined will be more complex in the future.

Yeah, too complex.

> I'm leaning pretty heavily toward the first option, but want to know how others feel about this.

+1

··· On 26/02/13 15:35, Sam Kottler wrote:


Dominic Cleal
Red Hat Engineering

I don't expect these to be big, I mean you will need to create few rules
to allow them to connect to sockets and this kind of stuff, but db
drivers do not usually create files.

So I tend to prefer 1 too.

··· On Tue, Feb 26, 2013 at 10:35:14AM -0500, Sam Kottler wrote: > I'm working on writing an SElinux policy for foreman and the proxy, both of which are nearly done. One of the final decisions that needs to be made, though, is how to handle different database backends. From my perspective there are really two ways to handle allowing connections to user's choice of database: > > 1. Include support for all three (pg, mysql, sqlite) databases in the foreman core selinux policy. This has the disadvantage of making the basic policy files more complex and *could* be a minor security risk because of unnecessary access, but it means that one policy (and subsequent package) meets the needs of all users. > 2. Create separate policies for each database and package them individually (i.e. foreman-selinux-postgresql). This just adds a lot of maintenance overhead and means that users have to install yet another package. It also makes locking foreman down via SElinux beyond allowing it to run unconfined will be more complex in the future. > > I'm leaning pretty heavily toward the first option, but want to know how others feel about this. Is potentially allowing access to a database other than the one being used by Foreman a policy decision we are okay with to reduce potential packaging and maintenance issues? > > -Sam > > -- > You received this message because you are subscribed to the Google Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > >


Later,

Lukas “lzap” Zapletal
#katello #systemengine

Spacewalk used first option and I did not seen problems.

Of course that main foreman selinux policy should include only those
rules which are needed just to connect and send data to DB.
If db server itself needs some selinux rule, then it needs to be in
separate package.
Pg and mysql are in Fedora main selinux package. For db servers, which
are not part of Fedora (e.g Oracle) you have to write it on your own.

Mirek

··· On 26.2.2013 17:45, Bryan Kearney wrote: > How does satellite handle this today? > >> 1. Include support for all three (pg, mysql, sqlite) databases in the >> foreman core selinux policy. This has the disadvantage of making the >> basic policy files more complex and *could* be a minor security risk >> because of unnecessary access, but it means that one policy (and >> subsequent package) meets the needs of all users.

>> How does satellite handle this today?
>>
>>> 1. Include support for all three (pg, mysql, sqlite) databases in the
>>> foreman core selinux policy. This has the disadvantage of making the
>>> basic policy files more complex and could be a minor security risk
>>> because of unnecessary access, but it means that one policy (and
>>> subsequent package) meets the needs of all users.
>
> Spacewalk used first option and I did not seen problems.

Cool, good to know there is a precedent!

>
> Of course that main foreman selinux policy should include only those
> rules which are needed just to connect and send data to DB.

Indeed.

> If db server itself needs some selinux rule, then it needs to be in
> separate package.
> Pg and mysql are in Fedora main selinux package. For db servers, which
> are not part of Fedora (e.g Oracle) you have to write it on your own.

Yep, I'm just going to piggyback on the existing policies for those
DB's. I think a very small number of people use things other than the
standard three DB's. I've never heard of anyone using mssql or Oracle
with Foreman, but maybe people have done so :slight_smile:

>
> Mirek
>
Thanks for the input - really appreciate it.

-Sam

··· On 02/26/2013 11:59 AM, Miroslav Suchy wrote: > On 26.2.2013 17:45, Bryan Kearney wrote: