This patch is intended to support MLS in database systems. It allows for
objects to be created/relabeled within target context objects that are
appropriate to contain the source's level. For the sake of analogy, we equate
dirs holding files of different levels to certain database objects holding
other database objects of different levels.
Mirror file/dir approach.
db objects which do not contain other objects at multiple levels are analogous
to files:
db_procedure
db_language
db_column
db_tuple
db_blob
db objects which are capable of holding objects at multiple levels are
analogous to dirs:
db_database
db_schema
db_table
db_sequence
db_view
---
policy/mls | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/policy/mls b/policy/mls
index 06e5106..c7c6fd5 100644
--- a/policy/mls
+++ b/policy/mls
@@ -763,8 +763,9 @@ mlsconstrain context contains
#
# make sure these database classes are "single level"
-mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
+mlsconstrain { db_procedure db_language db_column db_blob } { create relabelto }
( l2 eq h2 );
+
mlsconstrain { db_tuple } { insert relabelto }
( l2 eq h2 );
@@ -833,7 +834,7 @@ mlsconstrain { db_tuple } { use select }
( t1 == mlsdbread ) or
( t2 == mlstrustedobject ));
-# the "single level" file "write" ops
+# the "single level" database "write" ops
mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module set_param }
(( l1 eq l2 ) or
(( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
--
1.8.3.1
On Fri, Jan 15, 2016 at 4:21 PM, Mike Palmiotto
<[email protected]> wrote:
> Mirror file/dir approach.
>
> db objects which do not contain other objects at multiple levels are analogous
> to files:
> db_procedure
> db_language
> db_column
> db_tuple
> db_blob
>
> db objects which are capable of holding objects at multiple levels are
> analogous to dirs:
> db_database
> db_schema
> db_table
> db_sequence
> db_view
Figured this might be somewhat confusing so here is some more clarification.
As the constraint currently stands, we are unable to create/relabel
any object to a level range in Enforcing. By getting rid of the
"single level" constraint (l2 eq h2) on certain database objects, we
allow the ability to create a table containing objects within the
range s0-s2:c1.c4, for example.
For objects such as db_tuple, this does not currently make much sense,
as a tuple will never contain objects with "multiple levels."
Feel free to provide feedback/questions. I have a patch queued up to
submit for pull-request when the time comes.
> ---
> policy/mls | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/policy/mls b/policy/mls
> index 06e5106..c7c6fd5 100644
> --- a/policy/mls
> +++ b/policy/mls
> @@ -763,8 +763,9 @@ mlsconstrain context contains
> #
>
> # make sure these database classes are "single level"
> -mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
> +mlsconstrain { db_procedure db_language db_column db_blob } { create relabelto }
> ( l2 eq h2 );
> +
> mlsconstrain { db_tuple } { insert relabelto }
> ( l2 eq h2 );
>
> @@ -833,7 +834,7 @@ mlsconstrain { db_tuple } { use select }
> ( t1 == mlsdbread ) or
> ( t2 == mlstrustedobject ));
>
> -# the "single level" file "write" ops
> +# the "single level" database "write" ops
> mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module set_param }
> (( l1 eq l2 ) or
> (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> --
> 1.8.3.1
>
Thanks,
--Mike
2016-01-16 6:21 GMT+09:00 Mike Palmiotto <[email protected]>:
> Mirror file/dir approach.
>
> db objects which do not contain other objects at multiple levels are analogous
> to files:
> db_procedure
> db_language
> db_column
> db_tuple
> db_blob
>
> db objects which are capable of holding objects at multiple levels are
> analogous to dirs:
> db_database
> db_schema
> db_table
> db_sequence
> db_view
>
db_sequence and db_view also have no capability to contain another objects.
It may look like a view contain columns/tuples, however, it actually comes from
another tables. View is just an alias to tables, used to rewrite query.
So, I think these two class have analogy of files, rather than directories.
> policy/mls | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/policy/mls b/policy/mls
> index 06e5106..c7c6fd5 100644
> --- a/policy/mls
> +++ b/policy/mls
> @@ -763,8 +763,9 @@ mlsconstrain context contains
> #
>
> # make sure these database classes are "single level"
> -mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
> +mlsconstrain { db_procedure db_language db_column db_blob } { create relabelto }
> ( l2 eq h2 );
> +
> mlsconstrain { db_tuple } { insert relabelto }
> ( l2 eq h2 );
>
> @@ -833,7 +834,7 @@ mlsconstrain { db_tuple } { use select }
> ( t1 == mlsdbread ) or
> ( t2 == mlstrustedobject ));
>
> -# the "single level" file "write" ops
> +# the "single level" database "write" ops
> mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module set_param }
> (( l1 eq l2 ) or
> (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> --
> 1.8.3.1
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
KaiGai Kohei <[email protected]>
On Thu, Jan 21, 2016 at 9:05 AM, Kohei KaiGai <[email protected]> wrote:
> 2016-01-16 6:21 GMT+09:00 Mike Palmiotto <[email protected]>:
>> Mirror file/dir approach.
>>
>> db objects which do not contain other objects at multiple levels are analogous
>> to files:
>> db_procedure
>> db_language
>> db_column
>> db_tuple
>> db_blob
>>
>> db objects which are capable of holding objects at multiple levels are
>> analogous to dirs:
>> db_database
>> db_schema
>> db_table
>> db_sequence
>> db_view
>>
> db_sequence and db_view also have no capability to contain another objects.
>
> It may look like a view contain columns/tuples, however, it actually comes from
> another tables. View is just an alias to tables, used to rewrite query.
>
> So, I think these two class have analogy of files, rather than directories.
Sorry for the delayed response and thanks for the feedback!
I think it makes sense for sequences to and views to be single-level.
We're still digging into the complexity of views. As you said, they're
just a means to re-write a query; however, there is some added
complexity with respect to "expand." The issue is that expansion is
guided by a "read op" constraint, but in order to "insert" into the
view [underlying table], you need to first do an "expand." I believe
the conclusion we're coming to is that we need to enforce dominatable
levels on views so the constraint passes, though some digging still
needs to be done.
Additionally, we've determined that it makes more sense to let
db_columns be multi-level, as it can hold a range of row-values. Any
thoughts on the matter?
Updated patch to come.
>
>> policy/mls | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/policy/mls b/policy/mls
>> index 06e5106..c7c6fd5 100644
>> --- a/policy/mls
>> +++ b/policy/mls
>> @@ -763,8 +763,9 @@ mlsconstrain context contains
>> #
>>
>> # make sure these database classes are "single level"
>> -mlsconstrain { db_database db_schema db_table db_sequence db_view db_procedure db_language db_column db_blob } { create relabelto }
>> +mlsconstrain { db_procedure db_language db_column db_blob } { create relabelto }
>> ( l2 eq h2 );
>> +
>> mlsconstrain { db_tuple } { insert relabelto }
>> ( l2 eq h2 );
>>
>> @@ -833,7 +834,7 @@ mlsconstrain { db_tuple } { use select }
>> ( t1 == mlsdbread ) or
>> ( t2 == mlstrustedobject ));
>>
>> -# the "single level" file "write" ops
>> +# the "single level" database "write" ops
>> mlsconstrain { db_database } { create drop setattr relabelfrom install_module load_module set_param }
>> (( l1 eq l2 ) or
>> (( t1 == mlsdbwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
>> --
>> 1.8.3.1
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
>
> --
> KaiGai Kohei <[email protected]>
Thanks,
--Mike
> I think it makes sense for sequences to and views to be single-level.
> We're still digging into the complexity of views. As you said, they're
> just a means to re-write a query; however, there is some added
> complexity with respect to "expand." The issue is that expansion is
> guided by a "read op" constraint, but in order to "insert" into the
> view [underlying table], you need to first do an "expand." I believe
> the conclusion we're coming to is that we need to enforce dominatable
> levels on views so the constraint passes, though some digging still
> needs to be done.
I concur on db_sequence and db_view only allowing a single-level, that
makes sense to me. I believe db_sequence is a no-brainer really.
Though, db_view on the other hand as you have stated does provide some
interesting things to consider. But, given that 'expand' is really
the only relevant permission with a view, I can't make a convincing
argument with myself at this time that a view should be allowed a
range of levels.
> Additionally, we've determined that it makes more sense to let
> db_columns be multi-level, as it can hold a range of row-values. Any
> thoughts on the matter?
Yes, I believe it makes sense to allow db_column to be multi-level for
the same reasons that we would allow db_table. In that a column holds
multiple individual elements, those elements/tuples I think are what
are analogous to a 'file' not the column itself. I'd consider the
column to be more like a 'directory'.
-Adam