Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 02 Jun 2008 19:27:48 +0900
> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote: >> Christopher J. PeBenito wrote: >>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote: >>> >>>> Christopher J. PeBenito wrote: >>>> >>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote: >>>>> >>>>> >>>>>> Christopher J. PeBenito wrote: >>>>>> >>>>>> >>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote: >>>>>>>> >>>>>>>> >>>>>>>>> I mainly had an issue with statements like: >>>>>>>>> >>>>>>>>> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; >>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; >>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; >>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; >>>>>>>>> type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t; >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> I don't see the problem with the above statements - seems like a >>>>>> reasonable use of transitions to me. If you don't like the first four >>>>>> transitions, then I would ask -- why not simply eliminate the target >>>>>> types in those rules and label all of those objects with postgresql_t >>>>>> (default transition)? Clearly the names are just for convenience. You >>>>>> did a similar thing with the X policy: going through and combining types. >>>>>> >>>>>> >>>>> I don't think this is the same situation. Having a table labeled >>>>> postgresql_t doesn't make sense to me, since postgresql_t is the type of >>>>> the server process. Though, I suppose that if it wasn't an object >>>>> manager, then the objects would implicitly be postgresql_t and/or >>>>> postgresql_db_t. So to conclude my stream of consciousness, I'm >>>>> compelled by your argument, but I'm not sure its enough to change my >>>>> position >>>>> >>>> If it's not the same situation, it sounds pretty darn close: the X >>>> server also acts as a "client" when it starts up, and various objects >>>> are created by the server before any real clients connect. For example >>>> root window and default colormap. >>>> >>>> From xserver.if: >>>> >>>> # Labeling rules for default windows and colormaps >>>> type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t; >>>> >>> Its significantly different since this deals with derived types while >>> postgres doesn't. >>> >> That's the policy writer's decision to make. What if I make my own >> policy and I want to use derived types for postgres? > > I never argued that type transitions shouldn't work. My problem is the > default type in the absence of type transitions. In fact there are > derived types in the current postgres policy, and I'm fine with them. IIUC, SE-PostgreSQL has to decide the security context of a newly created objects as follows:
It differs from the behavior of setfscreatecon on filesystem, and will be confusable. I think the default come from configuration file should work, as if a user specifies a security context explicitly.
If I misunderstood and you want to add a feature like setfscreatecon,
adding a database parameter is more suitable implementation for postgresql,
like:
'system_u:object_r:sepgsql_secret_t:SystemHigh' Users can specify it on the frontend (psql), and it read ~/.psqlrc and apply it on the startup. However, I don't think TYPE_TRANSITION toward sepgsql_db_t, sepgsql_table_t, ... are unnecessary, even if such the default option is added, because we don't use setfscreatecon as alternatives of TYPE_TRANSITION on filesystem. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Eamon Walsh <ewalsh_at_tycho.nsa.gov> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 02 Jun 2008 13:31:42 -0400
>> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote: >> >>> Christopher J. PeBenito wrote: >>> >>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote: >>>> >>>> >>>>> Christopher J. PeBenito wrote: >>>>> >>>>> >>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Christopher J. PeBenito wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I mainly had an issue with statements like: >>>>>>>>>> >>>>>>>>>> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; >>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; >>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; >>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; >>>>>>>>>> type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t; >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> I don't see the problem with the above statements - seems like a >>>>>>> reasonable use of transitions to me. If you don't like the first four >>>>>>> transitions, then I would ask -- why not simply eliminate the target >>>>>>> types in those rules and label all of those objects with postgresql_t >>>>>>> (default transition)? Clearly the names are just for convenience. You >>>>>>> did a similar thing with the X policy: going through and combining types. >>>>>>> >>>>>>> >>>>>>> >>>>>> I don't think this is the same situation. Having a table labeled >>>>>> postgresql_t doesn't make sense to me, since postgresql_t is the type of >>>>>> the server process. Though, I suppose that if it wasn't an object >>>>>> manager, then the objects would implicitly be postgresql_t and/or >>>>>> postgresql_db_t. So to conclude my stream of consciousness, I'm >>>>>> compelled by your argument, but I'm not sure its enough to change my >>>>>> position >>>>>> >>>>>> >>>>> If it's not the same situation, it sounds pretty darn close: the X >>>>> server also acts as a "client" when it starts up, and various objects >>>>> are created by the server before any real clients connect. For example >>>>> root window and default colormap. >>>>> >>>>> From xserver.if: >>>>> >>>>> # Labeling rules for default windows and colormaps >>>>> type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t; >>>>> >>>>> >>>> Its significantly different since this deals with derived types while >>>> postgres doesn't. >>>> >>>> >>> That's the policy writer's decision to make. What if I make my own >>> policy and I want to use derived types for postgres? >>> >> I never argued that type transitions shouldn't work. My problem is the >> default type in the absence of type transitions. In fact there are >> derived types in the current postgres policy, and I'm fine with them. >> It sounds to me like selabel might be best for this. The tables, databases, procedures, and blobs have names, and those names can be used in a mapping to contexts. There can be setcreatecon overrides to this as well. selabel has a wildcard for setting a default context. But putting a hard-coded context into a file just to avoid a few type transition rules is totally bogus to me. I find it strange that it's considered a "simplification" to use a default_context file rather than policy rules, as though it's some kind of huge win. Adding a default_context file requires new libselinux API, which bloat affects all SELinux users. I've also never seen a coherent solution for managing these files. They are part of the security policy, which means updates to them must be atomic with the policy load or there will be race conditions affecting their users. > > IIUC, SE-PostgreSQL has to decide the security context of a newly created > objects as follows: > > 1. It invokes security_compute_create_raw() to decide the security context > of a newly created object, came from the policy. > 2. It checks whether it come from TYPE_TRANSITION rule, or not. > (What API is available to check it?) > There is no such API. Either a type transition is used to label something, or it isn't.
> 3. If there is no TYPE_TRANSITION rule, it refers the configuration file > > It differs from the behavior of setfscreatecon on filesystem, and will > be confusable. I think the default come from configuration file should > work, as if a user specifies a security context explicitly. > > If I misunderstood and you want to add a feature like setfscreatecon, > adding a database parameter is more suitable implementation for postgresql, > like: > postgres=# SET sepgsql_table_createcon \ > 'system_u:object_r:sepgsql_secret_t:SystemHigh' > > Users can specify it on the frontend (psql), and it read ~/.psqlrc and > apply it on the startup. > > However, I don't think TYPE_TRANSITION toward sepgsql_db_t, sepgsql_table_t, ... > are unnecessary, even if such the default option is added, because we don't > use setfscreatecon as alternatives of TYPE_TRANSITION on filesystem. > Like I said, given that the database objects are named, I think an selabel-based solution might be best here. -- Eamon Walsh <ewalsh@tycho.nsa.gov> National Security Agency -- 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.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 02 Jun 2008 14:39:15 -0400
I'm out of arguments; clearly I'm in the minority on this issue. I already said I wouldn't block the policy over this, so KaiGai, if you would send a last patch based on the revisions I made [1], let see if we can finally get this merged. [1] http://marc.info/?l=selinux&m=120999566809541&w=2 -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Tue, 03 Jun 2008 19:25:16 +0900
> On Mon, 2008-06-02 at 13:31 -0400, Eamon Walsh wrote: >> KaiGai Kohei wrote: >>> Christopher J. PeBenito wrote: >>>> On Thu, 2008-05-29 at 20:22 -0400, Eamon Walsh wrote: >>>>> Christopher J. PeBenito wrote: >>>>>> On Thu, 2008-05-29 at 14:05 -0400, Eamon Walsh wrote: >>>>>>> Christopher J. PeBenito wrote: >>>>>>>> On Tue, 2008-05-27 at 16:15 -0400, Eamon Walsh wrote: >>>>>>>>> Christopher J. PeBenito wrote: >>>>>>>>>> On Tue, 2008-05-27 at 14:34 -0400, Stephen Smalley wrote: >>>>>>>>>>> On Tue, 2008-05-27 at 13:55 -0400, Christopher J. PeBenito wrote: >>>>>>>>>>>> I mainly had an issue with statements like: >>>>>>>>>>>> >>>>>>>>>>>> type_transition postgresql_t postgresql_t:db_database sepgsql_db_t; >>>>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_table sepgsql_sysobj_t; >>>>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_procedure sepgsql_proc_t; >>>>>>>>>>>> type_transition postgresql_t sepgsql_database_type:db_blob sepgsql_blob_t; >>>>>>>>>>>> type_transition sepgsql_client_type postgresql_t:db_database sepgsql_db_t; >>>>>>>>>>>> >>>>>>>>> I don't see the problem with the above statements - seems like a >>>>>>>>> reasonable use of transitions to me. If you don't like the first four >>>>>>>>> transitions, then I would ask -- why not simply eliminate the target >>>>>>>>> types in those rules and label all of those objects with postgresql_t >>>>>>>>> (default transition)? Clearly the names are just for convenience. You >>>>>>>>> did a similar thing with the X policy: going through and combining types. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> I don't think this is the same situation. Having a table labeled >>>>>>>> postgresql_t doesn't make sense to me, since postgresql_t is the type of >>>>>>>> the server process. Though, I suppose that if it wasn't an object >>>>>>>> manager, then the objects would implicitly be postgresql_t and/or >>>>>>>> postgresql_db_t. So to conclude my stream of consciousness, I'm >>>>>>>> compelled by your argument, but I'm not sure its enough to change my >>>>>>>> position >>>>>>>> >>>>>>>> >>>>>>> If it's not the same situation, it sounds pretty darn close: the X >>>>>>> server also acts as a "client" when it starts up, and various objects >>>>>>> are created by the server before any real clients connect. For example >>>>>>> root window and default colormap. >>>>>>> >>>>>>> From xserver.if: >>>>>>> >>>>>>> # Labeling rules for default windows and colormaps >>>>>>> type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t; >>>>>>> >>>>>>> >>>>>> Its significantly different since this deals with derived types while >>>>>> postgres doesn't. >>>>>> >>>>>> >>>>> That's the policy writer's decision to make. What if I make my own >>>>> policy and I want to use derived types for postgres? >>>>> >>>> I never argued that type transitions shouldn't work. My problem is the >>>> default type in the absence of type transitions. In fact there are >>>> derived types in the current postgres policy, and I'm fine with them. >>>> >> It sounds to me like selabel might be best for this. The tables, >> databases, procedures, and blobs have names, and those names can be used >> in a mapping to contexts. There can be setcreatecon overrides to this as >> well. selabel has a wildcard for setting a default context. >> >> But putting a hard-coded context into a file just to avoid a few type >> transition rules is totally bogus to me. I find it strange that it's >> considered a "simplification" to use a default_context file rather than >> policy rules, as though it's some kind of huge win. Adding a >> default_context file requires new libselinux API, which bloat affects >> all SELinux users. I've also never seen a coherent solution for managing >> these files. They are part of the security policy, which means updates >> to them must be atomic with the policy load or there will be race >> conditions affecting their users. > > I'm out of arguments; clearly I'm in the minority on this issue. I > already said I wouldn't block the policy over this, so KaiGai, if you > would send a last patch based on the revisions I made [1], let see if we > can finally get this merged. > > [1] http://marc.info/?l=selinux&m=120999566809541&w=2
I'll submit a revised version later.
Before this, I want to modify the following points:
Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Tue, 03 Jun 2008 08:37:12 -0400
> > I'm out of arguments; clearly I'm in the minority on this issue. I Unfortunately self doesn't work in type_transitions.
> - postgresql_unconfined() interface should also associate a domin I don't understand what you mean about the dontaudits. Otherwise, you should recheck the unconfined rules. I'm fairly sure I copied anything relevant from the client rules into unconfined so I didn't have to add both attributes in postgresql_unconfined(). -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Wed, 04 Jun 2008 13:03:59 +0900
>> Christopher J. PeBenito wrote: > >>> I'm out of arguments; clearly I'm in the minority on this issue. I >>> already said I wouldn't block the policy over this, so KaiGai, if you >>> would send a last patch based on the revisions I made [1], let see if we >>> can finally get this merged. >>> >>> [1] http://marc.info/?l=selinux&m=120999566809541&w=2 >> I'll submit a revised version later. >> (Now we cannot update SVN repository, due to server maintenance.) >> >> Before this, I want to modify the following points: >> >> - neverallow rule should be removed, as you suggested before. >> >> - The type_transition rule for newly created database should be >> described with "self" as its target, like: >> type_transition sepgsql_client_type self : db_database sepgsql_db_t; >> The purpose is to make clear its meanings that this type_transition >> has no appropriate parent as socket creation. > > Unfortunately self doesn't work in type_transitions. Oops, >> - postgresql_unconfined() interface should also associate a domin >> with sepgsql_client_type, not only sepgsql_unconfined_type. >> dontaudit rules on row-level logs are not disabled for unconfined >> clients. And, it's not useful to write additional policy module. > > I don't understand what you mean about the dontaudits. Otherwise, you > should recheck the unconfined rules. I'm fairly sure I copied anything > relevant from the client rules into unconfined so I didn't have to add > both attributes in postgresql_unconfined(). A table can contain massive tuples in generally. If 50% of 1,000,000 tuples are labaled as "Classified" and hidden from clients (includes unconfined domain), tuple-level access denied log will make a flood of logs. The dontaudit rule enables to restain the problem. I intended sepgsql_client_type means all domains connectable to SE-PostgreSQL. If it dosen't contain unconfined domains, I think its name is a bit confusable and something like "sepgsql_unpriv_type" is better for its name. Then, the above dontaudit rule should be rewritten as follows: dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \ { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *; At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off tuple-level access logs, but you suggested it is unnecessary, so I removed it. In addition, I found an unclear point which came from my original policy. :( allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; A blob import interface enables to read a file on a server host by the server process (postgresql_t), and import to database as several frames of largeobject. A export interface works for inversed direction. In the previous discussion, the meaning of these permission is to indicate server process to start importing or exporting. However, I'm now considering the following rules are more sensefull:
Could you tell me your opinion? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Joshua Brindle <jbrindle_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Wed, 04 Jun 2008 10:19:45 -0400
<snip>
> Chris asked me to look at this for him. The access checks above seem completely reasonable to me, much better than the previous check. I wonder though, how you'll do an export check between the client and file type, since a compute_create between the client and the target directory may be different than between postgresql_t and the directory? Which context would you attempt to use? -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Thu, 05 Jun 2008 10:07:01 +0900
>> Christopher J. PeBenito wrote: > > <snip> > >> In addition, I found an unclear point which came from my original policy. :( >> >> allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; >> >> A blob import interface enables to read a file on a server host by the server >> process (postgresql_t), and import to database as several frames of largeobject. >> A export interface works for inversed direction. >> >> In the previous discussion, the meaning of these permission is to indicate >> server process to start importing or exporting. >> However, I'm now considering the following rules are more sensefull: >> >> 1. SE-PostgreSQL checks whether the client has db_blob:{import} for >> the target large object. db_blob:{write} is also checked here... >> 2. SE-PostgreSQL checks whether the client has file:{read} for >> the target file. >> 3. SELinux (kernel) checks whether postgresql_t has file:{read} for the >> target file, because it uses read(2) system call. >> >> Could you tell me your opinion? > > Chris asked me to look at this for him. The access checks above seem completely > reasonable to me, much better than the previous check. > > I wonder though, how you'll do an export check between the client and file type, > since a compute_create between the client and the target directory may be different > than between postgresql_t and the directory? Which context would you attempt to use? In export case, the target file is labeled as a newly created one between postgresql_t and its parent directly, as SELinux attaches in default. We can understand the behavior as PostgreSQL owns this file and delivers its file descriptor to the client. Thus, the client should be checked the file:{write} permission for the result of compute_create between postgresql_t and the parent directly. It does not give us any mismatching between DAC and MAC. So, I think it is more suitable than using setfscreatecon() to force the result between the client and the parent directly. In the conclusion, the following permissions will be checked for blob export.
Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Eamon Walsh <ewalsh_at_tycho.nsa.gov> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Thu, 05 Jun 2008 14:09:13 -0400
>> KaiGai Kohei wrote: >> >>> Christopher J. PeBenito wrote: >>> >> <snip> >> >> >>> In addition, I found an unclear point which came from my original policy. :( >>> >>> allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; >>> >>> A blob import interface enables to read a file on a server host by the server >>> process (postgresql_t), and import to database as several frames of largeobject. >>> A export interface works for inversed direction. >>> >>> In the previous discussion, the meaning of these permission is to indicate >>> server process to start importing or exporting. >>> However, I'm now considering the following rules are more sensefull: >>> >>> 1. SE-PostgreSQL checks whether the client has db_blob:{import} for >>> the target large object. >>> > > db_blob:{write} is also checked here... > > >>> 2. SE-PostgreSQL checks whether the client has file:{read} for >>> the target file. >>> 3. SELinux (kernel) checks whether postgresql_t has file:{read} for the >>> target file, because it uses read(2) system call. >>> >>> Could you tell me your opinion? >>> >> Chris asked me to look at this for him. The access checks above seem completely >> reasonable to me, much better than the previous check. >> >> I wonder though, how you'll do an export check between the client and file type, >> since a compute_create between the client and the target directory may be different >> than between postgresql_t and the directory? Which context would you attempt to use? >> > > In export case, the target file is labeled as a newly created one between > postgresql_t and its parent directly, as SELinux attaches in default. > > We can understand the behavior as PostgreSQL owns this file and delivers > its file descriptor to the client. Thus, the client should be checked > the file:{write} permission for the result of compute_create between > postgresql_t and the parent directly. > Doesn't the kernel handle this automatically? Which is to say, if you give a file descriptor to another process (I'm assuming it gets passed through the local socket), the kernel still checks read and write on every access.
> It does not give us any mismatching between DAC and MAC. > > In the conclusion, the following permissions will be checked for blob export. > > 1. SELinux (kernel) checks file:{write} between postgresql_t and the newly > created file which is labeled as the result between postgresql_t and > the parent directory. > This file is owned by PostgreSQL in DAC world. > 2. SE-PostgreSQL checks db_blob:{export read} between the client and the target > large object. > 3. SE-PostgreSQL checks file:{write} between the client and the target file. > > Thanks, > -- Eamon Walsh <ewalsh@tycho.nsa.gov> National Security Agency -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Fri, 06 Jun 2008 14:32:25 +0900
> KaiGai Kohei wrote: >> Joshua Brindle wrote: >> >>> KaiGai Kohei wrote: >>> >>>> Christopher J. PeBenito wrote: >>>> >>> <snip> >>> >>> >>>> In addition, I found an unclear point which came from my original policy. :( >>>> >>>> allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; >>>> >>>> A blob import interface enables to read a file on a server host by the server >>>> process (postgresql_t), and import to database as several frames of largeobject. >>>> A export interface works for inversed direction. >>>> >>>> In the previous discussion, the meaning of these permission is to indicate >>>> server process to start importing or exporting. >>>> However, I'm now considering the following rules are more sensefull: >>>> >>>> 1. SE-PostgreSQL checks whether the client has db_blob:{import} for >>>> the target large object. >>>> >> db_blob:{write} is also checked here... >> >> >>>> 2. SE-PostgreSQL checks whether the client has file:{read} for >>>> the target file. >>>> 3. SELinux (kernel) checks whether postgresql_t has file:{read} for the >>>> target file, because it uses read(2) system call. >>>> >>>> Could you tell me your opinion? >>>> >>> Chris asked me to look at this for him. The access checks above seem completely >>> reasonable to me, much better than the previous check. >>> >>> I wonder though, how you'll do an export check between the client and file type, >>> since a compute_create between the client and the target directory may be different >>> than between postgresql_t and the directory? Which context would you attempt to use? >>> >> In export case, the target file is labeled as a newly created one between >> postgresql_t and its parent directly, as SELinux attaches in default. >> >> We can understand the behavior as PostgreSQL owns this file and delivers >> its file descriptor to the client. Thus, the client should be checked >> the file:{write} permission for the result of compute_create between >> postgresql_t and the parent directly. >> > > Doesn't the kernel handle this automatically? Which is to say, if you > give a file descriptor to another process (I'm assuming it gets passed > through the local socket), the kernel still checks read and write on > every access. No, it seems to kernel as if the write() operation is done by postgresql server process. The facility of large object allows postgresql server process to read/write files on server host according to the operations come from client.
e.g)
This query come from client (but restricted to database super user) enables postgresql server process to read the given file and insert it as database records. All interactions between the kernel and userspace are done as normal i/o operations invoked by a server process, not a client. Thanks,
>> It does not give us any mismatching between DAC and MAC. >> >> In the conclusion, the following permissions will be checked for blob export. >> >> 1. SELinux (kernel) checks file:{write} between postgresql_t and the newly >> created file which is labeled as the result between postgresql_t and >> the parent directory. >> This file is owned by PostgreSQL in DAC world. >> 2. SE-PostgreSQL checks db_blob:{export read} between the client and the target >> large object. >> 3. SE-PostgreSQL checks file:{write} between the client and the target file. >> >> Thanks, >> > > -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Wed, 04 Jun 2008 10:32:10 -0400
> >> - postgresql_unconfined() interface should also associate a domin The fact is that we need an interface for unconfined access. If the privileged client access is equivalent to unconfined access, then I feel that the unconfined interface is clearer.
> Then, the above dontaudit rule should be rewritten as follows: I don't agree because of: +allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *; +allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *; so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do anything since the access is allowed.
> In addition, I found an unclear point which came from my original policy. :( I'll defer to Josh on this one since he knows much more about databases than I do. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Thu, 05 Jun 2008 10:18:04 +0900
> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote: >> Christopher J. PeBenito wrote: >>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote: >>>> Christopher J. PeBenito wrote: >>>>> I'm out of arguments; clearly I'm in the minority on this issue. I >>>>> already said I wouldn't block the policy over this, so KaiGai, if you >>>>> would send a last patch based on the revisions I made [1], let see if we >>>>> can finally get this merged. >>>>> >>>>> [1] http://marc.info/?l=selinux&m=120999566809541&w=2 >>>> I'll submit a revised version later. >>>> (Now we cannot update SVN repository, due to server maintenance.) >>>> >>>> Before this, I want to modify the following points: > >>>> - postgresql_unconfined() interface should also associate a domin >>>> with sepgsql_client_type, not only sepgsql_unconfined_type. >>>> dontaudit rules on row-level logs are not disabled for unconfined >>>> clients. And, it's not useful to write additional policy module. >>> I don't understand what you mean about the dontaudits. Otherwise, you >>> should recheck the unconfined rules. I'm fairly sure I copied anything >>> relevant from the client rules into unconfined so I didn't have to add >>> both attributes in postgresql_unconfined(). >> A table can contain massive tuples in generally. If 50% of 1,000,000 tuples >> are labaled as "Classified" and hidden from clients (includes unconfined >> domain), tuple-level access denied log will make a flood of logs. >> The dontaudit rule enables to restain the problem. >> >> I intended sepgsql_client_type means all domains connectable to SE-PostgreSQL. >> If it dosen't contain unconfined domains, I think its name is a bit confusable >> and something like "sepgsql_unpriv_type" is better for its name. > > The fact is that we need an interface for unconfined access. If the > privileged client access is equivalent to unconfined access, then I feel > that the unconfined interface is clearer. OK, it is clear enough for me.
>> Then, the above dontaudit rule should be rewritten as follows: >> >> At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off >> tuple-level access logs, but you suggested it is unnecessary, so I removed it. > > I don't agree because of: > > +allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *; > +allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *; > > so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do > anything since the access is allowed.
It is correct in type enforcement.
>> In addition, I found an unclear point which came from my original policy. :( >> >> allow sepgsql_unconfined_type postgresql_t:db_blob { import export }; >> >> A blob import interface enables to read a file on a server host by the server >> process (postgresql_t), and import to database as several frames of largeobject. >> A export interface works for inversed direction. >> >> In the previous discussion, the meaning of these permission is to indicate >> server process to start importing or exporting. >> However, I'm now considering the following rules are more sensefull: >> >> Could you tell me your opinion? > > I'll defer to Josh on this one since he knows much more about databases > than I do. -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Chris PeBenito <pebenito_at_gentoo.org> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Thu, 05 Jun 2008 09:35:16 -0400
> >> Then, the above dontaudit rule should be rewritten as follows: Ok, I see your point. Please add a comment in the policy that explains this, so I don't mistakenly remove the dontaudit in the future :) One thing I just realized: do we really want to dontaudit all perms? It seems like use and/or select might be sufficient. Dontauditing relabelto and relabelfrom doesn't seem like a good idea. -- Chris PeBenito <pebenito@gentoo.org> Developer, Hardened Gentoo Linux Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243 Key fingerprint = B0E6 877A 883F A57A 8E6A CB00 BC8E E42D E6AF 9243 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Fri, 06 Jun 2008 14:21:51 +0900
>> Christopher J. PeBenito wrote: >>> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote: >>>> Christopher J. PeBenito wrote: >>>>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote: >>>>>> Christopher J. PeBenito wrote: >>>>>>> I'm out of arguments; clearly I'm in the minority on this issue. I >>>>>>> already said I wouldn't block the policy over this, so KaiGai, if you >>>>>>> would send a last patch based on the revisions I made [1], let see if we >>>>>>> can finally get this merged. >>>>>>> >>>>>>> [1] http://marc.info/?l=selinux&m=120999566809541&w=2 >>>>>> I'll submit a revised version later. >>>>>> (Now we cannot update SVN repository, due to server maintenance.) >>>>>> >>>>>> Before this, I want to modify the following points: > >>>> Then, the above dontaudit rule should be rewritten as follows: >>>> >>>> dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \ >>>> { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *; >>>> >>>> At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off >>>> tuple-level access logs, but you suggested it is unnecessary, so I removed it. >>> I don't agree because of: >>> >>> +allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *; >>> +allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *; >>> >>> so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do >>> anything since the access is allowed. >> It is correct in type enforcement. >> But MCS/MLS can prevent to access by unconfined domains, and make flood of >> access denied logs. > > Ok, I see your point. Please add a comment in the policy that explains > this, so I don't mistakenly remove the dontaudit in the future :) > > One thing I just realized: do we really want to dontaudit all perms? It > seems like use and/or select might be sufficient. Dontauditing > relabelto and relabelfrom doesn't seem like a good idea. OK, I'll send the patch with a comment for tuple-level dontaudit and without dontaudit for relabelfrom/relabelto. Please wait for days. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 09 Jun 2008 12:07:01 +0900
[1] http://marc.info/?l=selinux&m=120999566809541&w=2
Thanks,
KaiGai Kohei wrote:
>> On Thu, 2008-06-05 at 10:18 +0900, KaiGai Kohei wrote: >>> Christopher J. PeBenito wrote: >>>> On Wed, 2008-06-04 at 13:03 +0900, KaiGai Kohei wrote: >>>>> Christopher J. PeBenito wrote: >>>>>> On Tue, 2008-06-03 at 19:25 +0900, KaiGai Kohei wrote: >>>>>>> Christopher J. PeBenito wrote: >>>>>>>> I'm out of arguments; clearly I'm in the minority on this issue. I >>>>>>>> already said I wouldn't block the policy over this, so KaiGai, if you >>>>>>>> would send a last patch based on the revisions I made [1], let see if we >>>>>>>> can finally get this merged. >>>>>>>> >>>>>>>> [1] http://marc.info/?l=selinux&m=120999566809541&w=2 >>>>>>> I'll submit a revised version later. >>>>>>> (Now we cannot update SVN repository, due to server maintenance.) >>>>>>> >>>>>>> Before this, I want to modify the following points: >>>>> Then, the above dontaudit rule should be rewritten as follows: >>>>> >>>>> dontaudit { sepgsql_client_type sepgsql_unpriv_type postgresql_t } \ >>>>> { sepgsql_table_type - sepgsql_sysobj_table_type } : db_tuple *; >>>>> >>>>> At first, I used a boolean (sepgsql_enable_audittuple) to turn on/off >>>>> tuple-level access logs, but you suggested it is unnecessary, so I removed it. >>>> I don't agree because of: >>>> >>>> +allow postgresql_t sepgsql_table_type:{ db_table db_column db_tuple } *; >>>> +allow sepgsql_unconfined_type sepgsql_table_type:{ db_table db_column db_tuple } *; >>>> >>>> so dontauditing for postgresql_t and sepgsql_unconfined_type doesn't do >>>> anything since the access is allowed. >>> It is correct in type enforcement. >>> But MCS/MLS can prevent to access by unconfined domains, and make flood of >>> access denied logs. >> Ok, I see your point. Please add a comment in the policy that explains >> this, so I don't mistakenly remove the dontaudit in the future :) >> >> One thing I just realized: do we really want to dontaudit all perms? It >> seems like use and/or select might be sufficient. Dontauditing >> relabelto and relabelfrom doesn't seem like a good idea. > > OK, I'll send the patch with a comment for tuple-level dontaudit and > without dontaudit for relabelfrom/relabelto. > > Please wait for days. > > Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Tue, 10 Jun 2008 14:09:15 -0400
I merged this, but I was thinking about some revisions that we should consider:
The client can only access the system database, not all databases, so it seems that sepgsql_database_type should be replaced with sepgsql_db_t. 2. the stored procedure type names have been in the back of my mind for long time but I couldn't come up with a good naming scheme. This especially bugged me for the sepgsql_trusted_domain_t and sepgsql_trusted_proc_t. Why not just go with what we do with regular domains and executables: sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Fri, 13 Jun 2008 19:39:53 +0900
I agreed. Currently, sepgsql_db_t is the only type of sepgsql_database_type except for unlabeled_t, however, these type_transition can prevent user to add new database type and new type_transition rules.
> 2. the stored procedure type names have been in the back of my mind for I don't have a clear reason for the naming of them. sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable for the purpose, I also think. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Fri, 13 Jun 2008 09:37:35 -0400
I merged this part of the patch.
> > 2. the stored procedure type names have been in the back of my mind for It seems that we should also rename $1_sepgsql_proc_t for consistency. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Wed, 18 Jun 2008 15:53:58 +0900
>> I don't have a clear reason for the naming of them. >> sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable >> for the purpose, I also think. > > It seems that we should also rename $1_sepgsql_proc_t for consistency. Sorry for late reply. At first, $1_sepgsql_proc_t lost the term of "trusted", so its name does not shows its purpose.
And, is there any differences between user_sepgsql_proc_t and
staff_sepgsql_proc_t?
But trusted procedure works as an unconfined database domain. There is no margin to customize except for MLS/MCS. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Wed, 18 Jun 2008 09:41:38 -0400
No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Fri, 20 Jun 2008 15:48:50 +0900
> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote: >> Christopher J. PeBenito wrote: >>>>> 2. the stored procedure type names have been in the back of my mind for >>>>> long time but I couldn't come up with a good naming scheme. This >>>>> especially bugged me for the sepgsql_trusted_domain_t and >>>>> sepgsql_trusted_proc_t. Why not just go with what we do with regular >>>>> domains and executables: sepgsql_trusted_proc_t and >>>>> sepgsql_trusted_proc_exec_t? >>>> I don't have a clear reason for the naming of them. >>>> sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable >>>> for the purpose, I also think. >>> It seems that we should also rename $1_sepgsql_proc_t for consistency. >> Sorry for late reply. >> >> At first, $1_sepgsql_proc_t lost the term of "trusted", so its name >> does not shows its purpose. > > No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t. Do you intend the following domain transition? user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t Is there any reason why users should not invoke their functions without domain transition? The purpose of $1_sepgsql_proc_t is to avoid unconfined domain to invoke user defined function (may be malicious one) without checking its safeness. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.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.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 23 Jun 2008 08:35:08 -0400
I don't think we need a transition. Mainly I think the procedure should be $1_sepgsql_proc_exec_t so there is naming consistency for stored procedures. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_kaigai.gr.jp> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 23 Jun 2008 21:48:34 +0900
> On Fri, 2008-06-20 at 15:48 +0900, KaiGai Kohei wrote: >> Christopher J. PeBenito wrote: >>> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote: >>>> Christopher J. PeBenito wrote: >>>>>>> 2. the stored procedure type names have been in the back of my mind for >>>>>>> long time but I couldn't come up with a good naming scheme. This >>>>>>> especially bugged me for the sepgsql_trusted_domain_t and >>>>>>> sepgsql_trusted_proc_t. Why not just go with what we do with regular >>>>>>> domains and executables: sepgsql_trusted_proc_t and >>>>>>> sepgsql_trusted_proc_exec_t? >>>>>> I don't have a clear reason for the naming of them. >>>>>> sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable >>>>>> for the purpose, I also think. >>>>> It seems that we should also rename $1_sepgsql_proc_t for consistency. >>>> Sorry for late reply. >>>> >>>> At first, $1_sepgsql_proc_t lost the term of "trusted", so its name >>>> does not shows its purpose. >>> No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t. >> Do you intend the following domain transition? >> user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t >> >> Is there any reason why users should not invoke their functions >> without domain transition? > > I don't think we need a transition. Mainly I think the procedure should > be $1_sepgsql_proc_exec_t so there is naming consistency for stored > procedures.
I agree it.
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.From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Mon, 23 Jun 2008 08:56:41 -0400
Well I didn't merge the trusted_proc patch yet, would you update that patch with $1_sepgsql_proc_exec_t too? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.From: KaiGai Kohei <kaigai_at_ak.jp.nec.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Tue, 24 Jun 2008 11:35:21 +0900
> On Mon, 2008-06-23 at 21:48 +0900, KaiGai Kohei wrote: >> Christopher J. PeBenito wrote: >>> On Fri, 2008-06-20 at 15:48 +0900, KaiGai Kohei wrote: >>>> Christopher J. PeBenito wrote: >>>>> On Wed, 2008-06-18 at 15:53 +0900, KaiGai Kohei wrote: >>>>>> Christopher J. PeBenito wrote: >>>>>>>>> 2. the stored procedure type names have been in the back of my mind for >>>>>>>>> long time but I couldn't come up with a good naming scheme. This >>>>>>>>> especially bugged me for the sepgsql_trusted_domain_t and >>>>>>>>> sepgsql_trusted_proc_t. Why not just go with what we do with regular >>>>>>>>> domains and executables: sepgsql_trusted_proc_t and >>>>>>>>> sepgsql_trusted_proc_exec_t? >>>>>>>> I don't have a clear reason for the naming of them. >>>>>>>> sepgsql_trusted_proc_t and sepgsql_trusted_proc_exec_t are more suitable >>>>>>>> for the purpose, I also think. >>>>>>> It seems that we should also rename $1_sepgsql_proc_t for consistency. >>>>>> Sorry for late reply. >>>>>> >>>>>> At first, $1_sepgsql_proc_t lost the term of "trusted", so its name >>>>>> does not shows its purpose. >>>>> No, I mean having a $1_sepgsql_proc_t and $1_sepgsql_proc_exec_t. >>>> Do you intend the following domain transition? >>>> user_t + user_sepgsql_proc_exec_t -> user_sepgsql_proc_t >>>> >>>> Is there any reason why users should not invoke their functions >>>> without domain transition? >>> I don't think we need a transition. Mainly I think the procedure should >>> be $1_sepgsql_proc_exec_t so there is naming consistency for stored >>> procedures. >> I agree it. >> Do you need a patch? > > Well I didn't merge the trusted_proc patch yet, would you update that > patch with $1_sepgsql_proc_exec_t too? The attached patch replaces the following names: $1_sepgsql_proc_t -> $1_sepgsql_proc_exec_t sepgsql_trusted_domain_t -> sepgsql_trusted_proc_t sepgsql_trusted_proc_t -> sepgsql_trusted_proc_exec_t Please apply, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>From: Christopher J. PeBenito <cpebenito_at_tresys.com> subject: Re: [PATCH] libselinux: add support for /contexts/postgresql_contexts Date: Tue, 24 Jun 2008 08:56:18 -0400
Merged.
> -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |