* sepgsql and process transition @ 2011-08-30 18:36 Joshua Brindle 2011-08-30 20:48 ` Kohei KaiGai 0 siblings, 1 reply; 10+ messages in thread From: Joshua Brindle @ 2011-08-30 18:36 UTC (permalink / raw) To: KaiGai Kohei, KaiGai Kohei; +Cc: SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-08-30 18:36 sepgsql and process transition Joshua Brindle @ 2011-08-30 20:48 ` Kohei KaiGai 2011-08-30 23:16 ` Joshua Brindle 2011-08-31 20:02 ` Joshua Brindle 0 siblings, 2 replies; 10+ messages in thread From: Kohei KaiGai @ 2011-08-30 20:48 UTC (permalink / raw) To: Joshua Brindle; +Cc: KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-08-30 20:48 ` Kohei KaiGai @ 2011-08-30 23:16 ` Joshua Brindle 2011-08-31 20:02 ` Joshua Brindle 1 sibling, 0 replies; 10+ messages in thread From: Joshua Brindle @ 2011-08-30 23:16 UTC (permalink / raw) To: Kohei KaiGai; +Cc: KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-08-30 20:48 ` Kohei KaiGai 2011-08-30 23:16 ` Joshua Brindle @ 2011-08-31 20:02 ` Joshua Brindle 2011-08-31 20:33 ` Kohei KaiGai 1 sibling, 1 reply; 10+ messages in thread From: Joshua Brindle @ 2011-08-31 20:02 UTC (permalink / raw) To: Kohei KaiGai; +Cc: KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-08-31 20:02 ` Joshua Brindle @ 2011-08-31 20:33 ` Kohei KaiGai 2011-09-01 9:33 ` Kohei Kaigai 0 siblings, 1 reply; 10+ messages in thread From: Kohei KaiGai @ 2011-08-31 20:33 UTC (permalink / raw) To: Joshua Brindle; +Cc: KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: sepgsql and process transition 2011-08-31 20:33 ` Kohei KaiGai @ 2011-09-01 9:33 ` Kohei Kaigai 2011-09-01 14:39 ` Joshua Brindle 0 siblings, 1 reply; 10+ messages in thread From: Kohei Kaigai @ 2011-09-01 9:33 UTC (permalink / raw) To: Kohei KaiGai, Joshua Brindle; +Cc: KaiGai Kohei, SE Linux, Stephen Smalley > > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-09-01 9:33 ` Kohei Kaigai @ 2011-09-01 14:39 ` Joshua Brindle 2011-09-01 15:51 ` Kohei Kaigai 0 siblings, 1 reply; 10+ messages in thread From: Joshua Brindle @ 2011-09-01 14:39 UTC (permalink / raw) To: Kohei Kaigai; +Cc: Kohei KaiGai, KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: sepgsql and process transition 2011-09-01 14:39 ` Joshua Brindle @ 2011-09-01 15:51 ` Kohei Kaigai 2011-09-01 18:36 ` Joshua Brindle 2011-09-01 19:13 ` Joshua Brindle 0 siblings, 2 replies; 10+ messages in thread From: Kohei Kaigai @ 2011-09-01 15:51 UTC (permalink / raw) To: Joshua Brindle; +Cc: Kohei KaiGai, KaiGai Kohei, SE Linux, Stephen Smalley > > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-09-01 15:51 ` Kohei Kaigai @ 2011-09-01 18:36 ` Joshua Brindle 2011-09-01 19:13 ` Joshua Brindle 1 sibling, 0 replies; 10+ messages in thread From: Joshua Brindle @ 2011-09-01 18:36 UTC (permalink / raw) To: Kohei Kaigai; +Cc: Kohei KaiGai, KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sepgsql and process transition 2011-09-01 15:51 ` Kohei Kaigai 2011-09-01 18:36 ` Joshua Brindle @ 2011-09-01 19:13 ` Joshua Brindle 1 sibling, 0 replies; 10+ messages in thread From: Joshua Brindle @ 2011-09-01 19:13 UTC (permalink / raw) To: Kohei Kaigai; +Cc: Kohei KaiGai, KaiGai Kohei, SE Linux, Stephen Smalley 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-01 19:13 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-30 18:36 sepgsql and process transition Joshua Brindle 2011-08-30 20:48 ` Kohei KaiGai 2011-08-30 23:16 ` Joshua Brindle 2011-08-31 20:02 ` Joshua Brindle 2011-08-31 20:33 ` Kohei KaiGai 2011-09-01 9:33 ` Kohei Kaigai 2011-09-01 14:39 ` Joshua Brindle 2011-09-01 15:51 ` Kohei Kaigai 2011-09-01 18:36 ` Joshua Brindle 2011-09-01 19:13 ` Joshua Brindle
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.