sepgsql and process transition

sepgsql and process transition

[Joshua Brindle]

Kaigai, I'm taking a look at the latest Postgresql master and I see that you are 
using process:transition permission to check access to transition from one type 
to another for trusted procedures.

Why didn't you add a transition permission to db_procedure? We are trying not to 
reuse kernel object classes for userspace object managers these days (I know we 
haven't been great about that in the past). I know this situation is a little 
tricky because the beginning type is a process type (domain) and the ending type 
is a procedure type, which closely maps to a domain type.

The beginning type may not always be a domain type though, if a procedure calls 
another procedure, or if postgres user session types become derived types 
(user_t -> sepgsql_user_t) we could completely divorce process types from 
postgres types.

Stephen, do you have an opinion on this?

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

Re: sepgsql and process transition

[Kohei KaiGai]

The reason why we check process:{transition} permission on invocation
of trusted procedures is an analogy to execution of program with
domain transition.

In the case of domain transition, it checks process:{transition}
permission on a pair of source and target domain, and it also checks
file:{entrypoint execute} permission on the security label of the file
to be launched.

Let's replace the file by a database object.
When a trusted procedure is invoked, it checks process:{transition}
permission on a pair of source and target *domain*. Please note that
"sepgsql_trusted_proc_t" is a domain, not an object within
db_procedure class.
And, it also checks db_procedure:{entrypoint execute} permission on
the security label of the procedure to be launched.

Also note that sepgsql_trusted_proc_exec_t is a label to be assigned
on db_procedure class; as an entrypoint of trusted procedure.


2011/8/30 Joshua Brindle <method@manicmethod.com>:
> Kaigai, I'm taking a look at the latest Postgresql master and I see that you
> are using process:transition permission to check access to transition from
> one type to another for trusted procedures.
>
> Why didn't you add a transition permission to db_procedure? We are trying
> not to reuse kernel object classes for userspace object managers these days
> (I know we haven't been great about that in the past). I know this situation
> is a little tricky because the beginning type is a process type (domain) and
> the ending type is a procedure type, which closely maps to a domain type.
>
> The beginning type may not always be a domain type though, if a procedure
> calls another procedure, or if postgres user session types become derived
> types (user_t -> sepgsql_user_t) we could completely divorce process types
> from postgres types.
>
> Stephen, do you have an opinion on this?
>



-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>

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

Re: sepgsql and process transition

[Joshua Brindle]

Kohei KaiGai wrote:
> The reason why we check process:{transition} permission on invocation
> of trusted procedures is an analogy to execution of program with
> domain transition.

Analogy, sure, but not a process and not a domain.

>
> In the case of domain transition, it checks process:{transition}
> permission on a pair of source and target domain, and it also checks
> file:{entrypoint execute} permission on the security label of the file
> to be launched.
>
> Let's replace the file by a database object.

That is the crux. A database object isn't a file and a stored procedure 
isn't a process. We've abused kernel object classes before but as far as 
I'm concerned we need to stop.

> When a trusted procedure is invoked, it checks process:{transition}
> permission on a pair of source and target *domain*. Please note that
> "sepgsql_trusted_proc_t" is a domain, not an object within
> db_procedure class.

It is a different class then, db_process, db_domain, whatever.

> And, it also checks db_procedure:{entrypoint execute} permission on
> the security label of the procedure to be launched.
>

> Also note that sepgsql_trusted_proc_exec_t is a label to be assigned
> on db_procedure class; as an entrypoint of trusted procedure.

Yes, so db_procedure is more like file, we need a database object class 
that is more like process.

>
>
> 2011/8/30 Joshua Brindle<method@manicmethod.com>:
>> Kaigai, I'm taking a look at the latest Postgresql master and I see that you
>> are using process:transition permission to check access to transition from
>> one type to another for trusted procedures.
>>
>> Why didn't you add a transition permission to db_procedure? We are trying
>> not to reuse kernel object classes for userspace object managers these days
>> (I know we haven't been great about that in the past). I know this situation
>> is a little tricky because the beginning type is a process type (domain) and
>> the ending type is a procedure type, which closely maps to a domain type.
>>
>> The beginning type may not always be a domain type though, if a procedure
>> calls another procedure, or if postgres user session types become derived
>> types (user_t ->  sepgsql_user_t) we could completely divorce process types
>> from postgres types.
>>
>> Stephen, do you have an opinion on this?
>>
>
>
>

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

Re: sepgsql and process transition

[Joshua Brindle]

Kohei KaiGai wrote:
> The reason why we check process:{transition} permission on invocation
> of trusted procedures is an analogy to execution of program with
> domain transition.
>
> In the case of domain transition, it checks process:{transition}
> permission on a pair of source and target domain, and it also checks
> file:{entrypoint execute} permission on the security label of the file
> to be launched.
>

I think I hit the exact reason why this bothers me today. As 
staff_t:SystemLow-SystemHigh I wanted a stored procedure that ran at 
sepgsql_trusted_proc_t:SystemHigh (so that it could read a SystemHigh column and 
fuzz the results).

Because of the current process constraint:
  mlsconstrain process transition
        (( h1 dom h2 ) and
         (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
          (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));

it isn't possible unless staff_t is part of privrangetrans and 
sepgsql_trusted_proc_t is part of mlsrangetrans. I don't mind the latter but the 
former is clearly a violation of how MLS is suppose to work on multi-level 
SELinux systems (in general, unprivileged users should not be able to change 
their level without going through newrole or logging out and back in).

If there was a different object class for procedures-while-executing, akin to 
process but called something different we could have a different constraint that 
made more sense for this use case.



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

Re: sepgsql and process transition

[Kohei KaiGai]

2011/8/31 Joshua Brindle <method@manicmethod.com>:
> Kohei KaiGai wrote:
>>
>> The reason why we check process:{transition} permission on invocation
>> of trusted procedures is an analogy to execution of program with
>> domain transition.
>>
>> In the case of domain transition, it checks process:{transition}
>> permission on a pair of source and target domain, and it also checks
>> file:{entrypoint execute} permission on the security label of the file
>> to be launched.
>>
>
> I think I hit the exact reason why this bothers me today. As
> staff_t:SystemLow-SystemHigh I wanted a stored procedure that ran at
> sepgsql_trusted_proc_t:SystemHigh (so that it could read a SystemHigh column
> and fuzz the results).
>
> Because of the current process constraint:
>  mlsconstrain process transition
>       (( h1 dom h2 ) and
>        (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
>         (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
>
> it isn't possible unless staff_t is part of privrangetrans and
> sepgsql_trusted_proc_t is part of mlsrangetrans. I don't mind the latter but
> the former is clearly a violation of how MLS is suppose to work on
> multi-level SELinux systems (in general, unprivileged users should not be
> able to change their level without going through newrole or logging out and
> back in).
>
> If there was a different object class for procedures-while-executing, akin
> to process but called something different we could have a different
> constraint that made more sense for this use case.
>
Hmm. I'd like to consider this matter for more details.

One other point I'm considering is what security label should be delivered to
when a database client want to invoke a remote procedure call using functions
installed to PostgreSQL. This feature is called 'foreign-data-wrapper' being
already merged at v9.1.
If we assign a subject entity that performs as an agent of client a security
label that is not a part of domain attribute, I'm not certain whether it is an
appropriate manner, or not.

BTW, Please don't hope to get this new object class into the upcoming v9.1,
because its feature freeze had done 9 months ago.

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


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

RE: sepgsql and process transition

[Kohei Kaigai]

> > I think I hit the exact reason why this bothers me today. As
> > staff_t:SystemLow-SystemHigh I wanted a stored procedure that ran at
> > sepgsql_trusted_proc_t:SystemHigh (so that it could read a SystemHigh column
> > and fuzz the results).
> >
> > Because of the current process constraint:
> >  mlsconstrain process transition
> >       (( h1 dom h2 ) and
> >        (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
> >         (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
> >
> > it isn't possible unless staff_t is part of privrangetrans and
> > sepgsql_trusted_proc_t is part of mlsrangetrans. I don't mind the latter but
> > the former is clearly a violation of how MLS is suppose to work on
> > multi-level SELinux systems (in general, unprivileged users should not be
> > able to change their level without going through newrole or logging out and
> > back in).
> >
> > If there was a different object class for procedures-while-executing, akin
> > to process but called something different we could have a different
> > constraint that made more sense for this use case.
> >
> Hmm. I'd like to consider this matter for more details.
> 
I think it is not a situation that we should allow staff_t:SystemLow-SystemHigh
to translate into sepgsql_trusted_proc_t:SystemHigh, because this rule intends
to prevent to switch lower range without special attributes, and it eventually
prevents violated references of information.
Even if we have individual object class to represent a subject entity of database
system, its fundamental is not changed, is it?

It seems to me a straightforward solution is to define an individual trusted
procedure type for MLS range transition (with mlsrangetrans), and restrict
subject entity to invoke this procedure (using privrangetrans).

> One other point I'm considering is what security label should be delivered to
> when a database client want to invoke a remote procedure call using functions
> installed to PostgreSQL. This feature is called 'foreign-data-wrapper' being
> already merged at v9.1.
> If we assign a subject entity that performs as an agent of client a security
> label that is not a part of domain attribute, I'm not certain whether it is an
> appropriate manner, or not.
> 
One other confusable situation is invocation of remote procedure from PostgreSQL.
If we try to set up multiple SE-PostgreSQL systems that communicate via labeled
networking each other, I'm afraid that analysis of domain transition becomes hard
because it allows multiple paths to translate other domains.

Right now, my opinion is that process:{translate} permission should be checked
when a subject entity of (operating|database) system tried to be switched.

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@emea.nec.com>


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

Re: sepgsql and process transition

[Joshua Brindle]

Kohei Kaigai wrote:
>>> I think I hit the exact reason why this bothers me today. As
>>> staff_t:SystemLow-SystemHigh I wanted a stored procedure that ran at
>>> sepgsql_trusted_proc_t:SystemHigh (so that it could read a SystemHigh column
>>> and fuzz the results).
>>>
>>> Because of the current process constraint:
>>>   mlsconstrain process transition
>>>        (( h1 dom h2 ) and
>>>         (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
>>>          (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
>>>
>>> it isn't possible unless staff_t is part of privrangetrans and
>>> sepgsql_trusted_proc_t is part of mlsrangetrans. I don't mind the latter but
>>> the former is clearly a violation of how MLS is suppose to work on
>>> multi-level SELinux systems (in general, unprivileged users should not be
>>> able to change their level without going through newrole or logging out and
>>> back in).
>>>
>>> If there was a different object class for procedures-while-executing, akin
>>> to process but called something different we could have a different
>>> constraint that made more sense for this use case.
>>>
>> Hmm. I'd like to consider this matter for more details.
>>
> I think it is not a situation that we should allow staff_t:SystemLow-SystemHigh
> to translate into sepgsql_trusted_proc_t:SystemHigh, because this rule intends
> to prevent to switch lower range without special attributes, and it eventually
> prevents violated references of information.
> Even if we have individual object class to represent a subject entity of database
> system, its fundamental is not changed, is it?

If staff running at system low need to use a trusted procedure to get (and 
redact, remove precision, etc) system high data they must be able to transition 
like that. Even if the user is running at systemlow-systemhigh, since their 
active clearance is systemlow, their user type must have privrangetrans which is 
not desirable.

>
> It seems to me a straightforward solution is to define an individual trusted
> procedure type for MLS range transition (with mlsrangetrans), and restrict
> subject entity to invoke this procedure (using privrangetrans).
>

We don't want to give privrangetrans to unprivileged user domains though.

>> One other point I'm considering is what security label should be delivered to
>> when a database client want to invoke a remote procedure call using functions
>> installed to PostgreSQL. This feature is called 'foreign-data-wrapper' being
>> already merged at v9.1.
>> If we assign a subject entity that performs as an agent of client a security
>> label that is not a part of domain attribute, I'm not certain whether it is an
>> appropriate manner, or not.
>>
> One other confusable situation is invocation of remote procedure from PostgreSQL.
> If we try to set up multiple SE-PostgreSQL systems that communicate via labeled
> networking each other, I'm afraid that analysis of domain transition becomes hard
> because it allows multiple paths to translate other domains.
>

The tools will need to be updated to handle the additional transition via db 
procedure but the analysis is no different than a domain transition or 
transitive information flow analysis of today.

> Right now, my opinion is that process:{translate} permission should be checked
> when a subject entity of (operating|database) system tried to be switched.
>

trusted procedures are not processes and should not use the process object class.


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

RE: sepgsql and process transition

[Kohei Kaigai]

> > I think it is not a situation that we should allow staff_t:SystemLow-SystemHigh
> > to translate into sepgsql_trusted_proc_t:SystemHigh, because this rule intends
> > to prevent to switch lower range without special attributes, and it eventually
> > prevents violated references of information.
> > Even if we have individual object class to represent a subject entity of database
> > system, its fundamental is not changed, is it?
> 
> If staff running at system low need to use a trusted procedure to get (and
> redact, remove precision, etc) system high data they must be able to transition
> like that. Even if the user is running at systemlow-systemhigh, since their
> active clearance is systemlow, their user type must have privrangetrans which is
> not desirable.
> 
If we add "db_client" as a new object class for a subject entity of database system,
How does the MLS constraint of db_client control the domain transition?
I guess the rule shall follow the process class:

  mlsconstrain db_client transition
          (( h1 dom h2 ) and
            (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
            (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));

However, in this case, staff_t still requires privrangetrans and sepgsql_trusted_proc_t
requires mlsrangetrans. If we exceptionally allows to upgrade/downgrade range of subject
entity on database system, unlike operating system, it is arguable...

> >> One other point I'm considering is what security label should be delivered to
> >> when a database client want to invoke a remote procedure call using functions
> >> installed to PostgreSQL. This feature is called 'foreign-data-wrapper' being
> >> already merged at v9.1.
> >> If we assign a subject entity that performs as an agent of client a security
> >> label that is not a part of domain attribute, I'm not certain whether it is an
> >> appropriate manner, or not.
> >>
> > One other confusable situation is invocation of remote procedure from PostgreSQL.
> > If we try to set up multiple SE-PostgreSQL systems that communicate via labeled
> > networking each other, I'm afraid that analysis of domain transition becomes hard
> > because it allows multiple paths to translate other domains.
> >
> 
> The tools will need to be updated to handle the additional transition via db
> procedure but the analysis is no different than a domain transition or
> transitive information flow analysis of today.
> 
It is OK for me at this point.

> > Right now, my opinion is that process:{translate} permission should be checked
> > when a subject entity of (operating|database) system tried to be switched.
> >
> 
> trusted procedures are not processes and should not use the process object class.
> 
We may need to have an upper meta-level viewpoint.

When a subject entity appeared in operating system, we call it "process".
When a subject entity appeared in database system, we call it something like "db_client".
And, a subject entity appeared in operating system tries to access database objects,
its security label is dealt with "db_client" class. Hmm.

Thanks,
--
NEC Europe Ltd, SAP Global Competence Center
KaiGai Kohei <kohei.kaigai@emea.nec.com>


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

Re: sepgsql and process transition

[Joshua Brindle]

Kohei Kaigai wrote:
<snip>
>> trusted procedures are not processes and should not use the process object class.
>>
> We may need to have an upper meta-level viewpoint.
>
> When a subject entity appeared in operating system, we call it "process".
> When a subject entity appeared in database system, we call it something like "db_client".
> And, a subject entity appeared in operating system tries to access database objects,
> its security label is dealt with "db_client" class. Hmm.
>

It isn't that surprising. When processes create sockets they are labeled as the 
process label by default, files in /proc/<pid> are labeled as the process label. 
Just because the label is the same doesn't mean the object class is.

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

Re: sepgsql and process transition

[Joshua Brindle]

Kohei Kaigai wrote:
>>> I think it is not a situation that we should allow staff_t:SystemLow-SystemHigh
>>> to translate into sepgsql_trusted_proc_t:SystemHigh, because this rule intends
>>> to prevent to switch lower range without special attributes, and it eventually
>>> prevents violated references of information.
>>> Even if we have individual object class to represent a subject entity of database
>>> system, its fundamental is not changed, is it?
>> If staff running at system low need to use a trusted procedure to get (and
>> redact, remove precision, etc) system high data they must be able to transition
>> like that. Even if the user is running at systemlow-systemhigh, since their
>> active clearance is systemlow, their user type must have privrangetrans which is
>> not desirable.
>>
> If we add "db_client" as a new object class for a subject entity of database system,
> How does the MLS constraint of db_client control the domain transition?
> I guess the rule shall follow the process class:
>
>    mlsconstrain db_client transition
>            (( h1 dom h2 ) and
>              (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or
>              (( t1 == privrangetrans ) and ( t2 == mlsrangetrans ))));
>
> However, in this case, staff_t still requires privrangetrans and sepgsql_trusted_proc_t
> requires mlsrangetrans. If we exceptionally allows to upgrade/downgrade range of subject
> entity on database system, unlike operating system, it is arguable...
>

I assume we'll have different attributes so that OS privileges and DB privileges 
can be separated.

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