Joshua Brindle wrote:
Andy Warner wrote:
KaiGai and I talked about this a bit already, and I'll preface my
response by saying that my memory of it is poor. Also, this issue was
one of my first practical introductions to selinux, so I'm sure I was
shooting in the dark. But, the main issue revolved around the type
transition rule for the database object. It seems to me, what makes it
special is that it has no parent object. It seems equivalent to writing
a type transition rule for creating the OS root directory, except in our
DBMS case we can have more than one type (each dbms has their own).
A rule for sepostgres is:
type_transition sepgsql_client_type sepgsql_client_type : db_database
sepgsql_db_t;
Where I believe the standard user_t and such had the sepgsql_client_type
attribute. So, with that rule in place I think it was impossible for
rubix to have a similar rule, if our client_type's overlapped. Which
seems likely, as the user_t is a likely candidate for a client. For
instance, if I did this:
strange, I thought he/we decided to use the domain of the dbms as the target for
that type_transition. That would solve this particular problem, I'd have to go
back in archives to understand why this path was chosen, or perhaps KaiGai
remembers.
type_transition rubix_client_type rubix_client_type : db_database
rubix_db_t; (where rubix_client_type contained user_t)
I think it would not compile because its ambiguous, right? So, what I
did was write a rule like this:
type_transition rubix_client_type rubix_t : db_database rubix_db_t;
and hard-coded the rubix_t into the avc_compute_create call. The rubix_t
is actually the type of our server process. Prior to doing that, I could
not find a way to not have a database be created with a sepgsql_t type.
If you just used the dbms domain as the target you wouldn't need to hardcode
anything.
Actually, thats what I did. My choice of words (hardcoding) wasn't the
best
I see (now) that the reference policy also has the rule:
type_transition postgresql_t postgresql_t : db_database sepgsql_db_t;
Obviously, the above would never conflict with another dbms's rules. If
that single type transition rule satisfied all of seposgresql's needs,
then that would eliminate the need for the conflicting rule. Though, I
assume thats dependent on the internals of seposgresql.
This is for internally created db objects? Why are both this and the client ->
client transitions needed?
<snip>
Yes, I don't mean they'd be using an identical policy but shared
templates/interfaces that worked with both would certainly make it easier to
target both systems without really needing to know the intricacies of each
systems enforcement.
Sounds like a good goal.
It may be a pipe dream, like having a common policy for all MTA's. At least if
there is some consensus on the internal object model, and since SQL is pretty
much the same everywhere this may actually stand a chance.
I like to be in that loop
|
