From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6LNB5ah021415 for ; Mon, 21 Jul 2008 19:11:05 -0400 Received: from house.lunarmania.com (jazzdrum.ncsc.mil [144.51.5.7]) by zombie.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6LNB4E6004169 for ; Mon, 21 Jul 2008 23:11:05 GMT Received: from 78-3-104-211.adsl.net.t-com.hr ([78.3.104.211] helo=[192.168.1.22]) by house.lunarmania.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KL4Wx-00060h-SD for selinux@tycho.nsa.gov; Mon, 21 Jul 2008 16:11:02 -0700 Message-ID: <48851770.5020002@rubix.com> Date: Tue, 22 Jul 2008 01:10:40 +0200 From: Andrew Warner MIME-Version: 1.0 To: selinux@tycho.nsa.gov Subject: questions about persistent storage of security contexts Content-Type: multipart/alternative; boundary="------------010200060207060006040407" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------010200060207060006040407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) that is characterized by: 1. The need to store a security context (in some recoverable form) in our persistent database (storage size of the context is an important factor) 2. The need to frequently perform a high number of security access checks in a performance sensitive way My question relates to the first characteristic from above. I am having trouble deciding on the best way to store the security context in the database. From my research I see (I think!) three different representations for a security context: 1) string; 2) raw; 3) SID. The string representation, generally, seems clear as this is what is shown in all documentation as the context representation that exists in user space. My only question regarding the string representation is: is there is any hard limit to the length of the security context string? Do I need to allow for no theoretical size limit on a context string if I choose to store it? I am inferring the the raw representation exists from seeing *_raw functions (e.g., security_compute_create_raw) referenced in selinux header files. Other than seeing these functions declared I am having trouble finding out much about a raw representation. Is there any advantage to storing/manipulating a context in its raw representation? That is, are they more suited for a fast security access check, are they smaller in size, or do they have a fixed or maximum length? The SID I have also seen mentioned in various documentations but can determine little about them. My guess is that they are an integer value that is used for fast internal access, particularly for the AVC. Are SIDs indeed integer values? Are they persistent or are they meaningful only for a particular OS session? I have also considered maintaining my own internal, persistent mapping between string based contexts and an integer representation, the mapping being stored/indexed inside the DBMS. This gives me a small storage overhead with a fixed size. Any answers, pointers to documentation, or other help would be greatly appreciated! Andy Warner --------------010200060207060006040407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello,

I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) that is characterized by:

1. The need to store a security context (in some recoverable form) in our persistent database (storage size of the context is an important factor)
2. The need to frequently perform a high number of security access checks in a performance sensitive way

My question relates to the first characteristic from above. I am having trouble deciding on the best way to store the security context in the database. From my research I see (I think!) three different representations for a security context: 1) string; 2) raw; 3) SID.

The string representation, generally, seems clear as this is what is shown in all documentation as the context representation that exists in user space. My only question regarding the string representation is: is there is any hard limit to the length of the security context string? Do I need to allow for no theoretical size limit on a context string if I choose to store it?

I am inferring the the raw representation exists from seeing *_raw functions (e.g., security_compute_create_raw) referenced in selinux header files. Other than seeing these functions declared I am having trouble finding out much about a raw representation. Is there any advantage to storing/manipulating a context in its raw representation? That is, are they more suited for a fast security access check, are they smaller in size, or do they have a fixed or maximum length?

The SID I have also seen mentioned in various documentations but can determine little about them. My guess is that they are an integer value that is used for fast internal access, particularly for the AVC. Are SIDs indeed integer values? Are they persistent or are they meaningful only for a particular OS session?

I have also considered maintaining my own internal, persistent mapping between string based contexts and an integer representation, the mapping being stored/indexed inside the DBMS. This gives me a small storage overhead with a fixed size.

Any answers, pointers to documentation, or other help would be greatly appreciated!

Andy Warner

--------------010200060207060006040407-- -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6M0ZW7a028508 for ; Mon, 21 Jul 2008 20:35:32 -0400 Received: from wa-out-1112.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6M0ZVmn026029 for ; Tue, 22 Jul 2008 00:35:31 GMT Received: by wa-out-1112.google.com with SMTP id k17so849843waf.0 for ; Mon, 21 Jul 2008 17:35:30 -0700 (PDT) Message-ID: <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> Date: Mon, 21 Jul 2008 20:35:30 -0400 From: "Eric Paris" To: "Andrew Warner" Subject: Re: questions about persistent storage of security contexts Cc: selinux@tycho.nsa.gov In-Reply-To: <48851770.5020002@rubix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <48851770.5020002@rubix.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Mon, Jul 21, 2008 at 7:10 PM, Andrew Warner wrote: > Hello, > > I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) > that is characterized by: > > 1. The need to store a security context (in some recoverable form) in our > persistent database (storage size of the context is an important factor) > 2. The need to frequently perform a high number of security access checks in > a performance sensitive way > > My question relates to the first characteristic from above. I am having > trouble deciding on the best way to store the security context in the > database. From my research I see (I think!) three different representations > for a security context: 1) string; 2) raw; 3) SID. > > The string representation, generally, seems clear as this is what is shown > in all documentation as the context representation that exists in user > space. My only question regarding the string representation is: is there is > any hard limit to the length of the security context string? Do I need to > allow for no theoretical size limit on a context string if I choose to store > it? No hard limit that I can think of. There might be one somewhere but I wouldn't count on it. > I am inferring the the raw representation exists from seeing *_raw functions > (e.g., security_compute_create_raw) referenced in selinux header files. > Other than seeing these functions declared I am having trouble finding out > much about a raw representation. Is there any advantage to > storing/manipulating a context in its raw representation? That is, are they > more suited for a fast security access check, are they smaller in size, or > do they have a fixed or maximum length? The _raw is actually what you want. _raw basically just means strings without any translations from things like mcstransd. Given a context like user_u:role_r:type_t the "raw" on an MLS system maybe "user_u:object_r:type_t::s0." Throwing a context with the MLS portion attched at the !raw functions will work just fine. > The SID I have also seen mentioned in various documentations but can > determine little about them. My guess is that they are an integer value that > is used for fast internal access, particularly for the AVC. Are SIDs indeed > integer values? Are they persistent or are they meaningful only for a > particular OS session? That's exactly what they are. They are kernel internal integer representations that are (for the most part) only meaningful for that session. There are some 'initial sids' that are always the same, but no userspace app should care about 'sids' in the general sense. > I have also considered maintaining my own internal, persistent mapping > between string based contexts and an integer representation, the mapping > being stored/indexed inside the DBMS. This gives me a small storage overhead > with a fixed size. I don't have a problem with internal mapping like that. But, don't we already have sepostgresql? Maybe you should be looking to see if that fits your needs or you might get ideas from the work that they performed? -Eric -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6M1f7To001350 for ; Mon, 21 Jul 2008 21:41:07 -0400 Received: from tyo201.gate.nec.co.jp (jazzdrum.ncsc.mil [144.51.5.7]) by zombie.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6M1f5Og025236 for ; Tue, 22 Jul 2008 01:41:06 GMT Message-ID: <48853AA5.3040607@ak.jp.nec.com> Date: Tue, 22 Jul 2008 10:40:53 +0900 From: KaiGai Kohei MIME-Version: 1.0 To: Andrew Warner CC: Eric Paris , selinux@tycho.nsa.gov Subject: Re: questions about persistent storage of security contexts References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> In-Reply-To: <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov >> I have also considered maintaining my own internal, persistent mapping >> between string based contexts and an integer representation, the mapping >> being stored/indexed inside the DBMS. This gives me a small storage overhead >> with a fixed size. > > I don't have a problem with internal mapping like that. In SE-PostgreSQL, it maintains own internal mapping between text represented security context and its integer identifier. The 'pg_security' system catalog stores the pair of them. Any tuple (including system catalog) has its security context. It is stored within padding area of HeapTupleHeader as an integer value, and it means the primary key of 'pg_security' system catalog. It also enables to boost userspace AVC, because this idea makes possible to implement it using a relationship between identifiers (not a text representation). When the security policy is reloaded and it makes invalidate the stored context, the stored one is dealt as 'unlabeled_t'. > But, don't we already have sepostgresql? Maybe you should be looking > to see if that fits your needs or you might get ideas from the work > that they performed? FYI: http://code.google.com/p/sepgsql/ Andrew, what is your intended base RDBMS? Currently, SE-PostgreSQL is the only SELinux awared RDBMS. It is now under reviewing for the next release (v8.4) cycle. http://wiki.postgresql.org/wiki/CommitFest:2008-07 However, I think we can apply SELinux for any other relational model implementation. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6M22npB003184 for ; Mon, 21 Jul 2008 22:02:49 -0400 Received: from yw-out-1718.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6M22nmn007879 for ; Tue, 22 Jul 2008 02:02:49 GMT Received: by yw-out-1718.google.com with SMTP id 6so619116ywa.84 for ; Mon, 21 Jul 2008 19:02:49 -0700 (PDT) Subject: Re: questions about persistent storage of security contexts From: Stephen Smalley To: Eric Paris Cc: Andrew Warner , selinux@tycho.nsa.gov In-Reply-To: <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> Content-Type: text/plain Date: Mon, 21 Jul 2008 22:01:03 -0400 Message-Id: <1216692067.17786.21.camel@sulphur> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Mon, 2008-07-21 at 20:35 -0400, Eric Paris wrote: > On Mon, Jul 21, 2008 at 7:10 PM, Andrew Warner wrote: > > Hello, > > > > I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) > > that is characterized by: > > > > 1. The need to store a security context (in some recoverable form) in our > > persistent database (storage size of the context is an important factor) > > 2. The need to frequently perform a high number of security access checks in > > a performance sensitive way > > > > My question relates to the first characteristic from above. I am having > > trouble deciding on the best way to store the security context in the > > database. From my research I see (I think!) three different representations > > for a security context: 1) string; 2) raw; 3) SID. > > > > The string representation, generally, seems clear as this is what is shown > > in all documentation as the context representation that exists in user > > space. My only question regarding the string representation is: is there is > > any hard limit to the length of the security context string? Do I need to > > allow for no theoretical size limit on a context string if I choose to store > > it? > > No hard limit that I can think of. There might be one somewhere but I > wouldn't count on it. Correct - the core logic imposes no fixed limits on the context strings, although the kernel interfaces do impose certain practical limits (e.g. page size). The NFSv4 support will likewise impose certain limits in accordance with existing limits on the size of containing structures. > > I am inferring the the raw representation exists from seeing *_raw functions > > (e.g., security_compute_create_raw) referenced in selinux header files. > > Other than seeing these functions declared I am having trouble finding out > > much about a raw representation. Is there any advantage to > > storing/manipulating a context in its raw representation? That is, are they > > more suited for a fast security access check, are they smaller in size, or > > do they have a fixed or maximum length? > > The _raw is actually what you want. _raw basically just means strings > without any translations from things like mcstransd. Given a context > like user_u:role_r:type_t the "raw" on an MLS system maybe > "user_u:object_r:type_t::s0." Throwing a context with the MLS portion > attched at the !raw functions will work just fine. > > > The SID I have also seen mentioned in various documentations but can > > determine little about them. My guess is that they are an integer value that > > is used for fast internal access, particularly for the AVC. Are SIDs indeed > > integer values? Are they persistent or are they meaningful only for a > > particular OS session? > > That's exactly what they are. They are kernel internal integer > representations that are (for the most part) only meaningful for that > session. There are some 'initial sids' that are always the same, but > no userspace app should care about 'sids' in the general sense. > > > I have also considered maintaining my own internal, persistent mapping > > between string based contexts and an integer representation, the mapping > > being stored/indexed inside the DBMS. This gives me a small storage overhead > > with a fixed size. > > I don't have a problem with internal mapping like that. The original SELinux filesystem labeling implementation used something like that - they were called "persistent security identifiers" (PSIDs), and were maintained as private indices per-filesystem that mapped to security context strings. > But, don't we already have sepostgresql? Maybe you should be looking > to see if that fits your needs or you might get ideas from the work > that they performed? Yes, I'd recommend looking at SE-PostgreSQL as a worked example of applying the Flask architecture to a DBMS, including not only its approach to storing security contexts but also its approach to the userspace AVC. You can find a link to that work from the Related Work page off of the SELinux web site. -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MAe6bh010102 for ; Tue, 22 Jul 2008 06:40:06 -0400 Received: from house.lunarmania.com (jazzdrum.ncsc.mil [144.51.5.7]) by zombie.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MAe5fY018968 for ; Tue, 22 Jul 2008 10:40:05 GMT Message-ID: <4885B8EB.9040809@rubix.com> Date: Tue, 22 Jul 2008 12:39:39 +0200 From: Andrew Warner MIME-Version: 1.0 To: KaiGai Kohei CC: Eric Paris , selinux@tycho.nsa.gov Subject: Re: questions about persistent storage of security contexts References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <48853AA5.3040607@ak.jp.nec.com> In-Reply-To: <48853AA5.3040607@ak.jp.nec.com> Content-Type: multipart/alternative; boundary="------------060002060100020809070400" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------060002060100020809070400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the information. I have previously looked at the SE-PostgreSQL code/documentation. It was helpful and most interesting. The base DBMS I am using is called Trusted RUBIX, which is an CC EAL-4 (Trusted Solaris) evaluated MLS DBMS. We have been contracted to integrate SELinux TE and MLS (Red Hat flavor) into our DBMS. So, obviously using SE-PostgreSQL is not an option :-) In the bigger picture, this current work is a small (and rather detached) step towards a high robustness (EAL-6+) DBMS solution. Historically, our company (and myself personally) have been involved in high(er) assurance MLS DBMS products/research for a number of years. As such, we tend to use a more "traditional" minimized trust, reference monitor architecture as opposed to inserting hooks and using query modification for our security enforcement. This means, for instance, that a label object permeates much of our kernel code at a fairly low level as well as storage objects. Thus, the runtime and storage representation must be chosen carefully as it will touch much of our kernel code. We also support full polyinstantiation of named objects, which dictates an efficient label mechanism. (Integration of TE + MLS into traditional MLS polyinstantiation behavior is an interesting topic!) Out of curiosity, KaiGai, a question about how SE-PostgreSQL presents the security context to a user. From your security guide I see that the context is a selectable column. But, what SQL type is the column? For instance, do you define your own SQL type, such as "Security Context" or is it a VARCHAR that has special constraints placed upon it to force it to conform to the structure of a security context? Blessings, Andy KaiGai Kohei wrote: >>> I have also considered maintaining my own internal, persistent mapping >>> between string based contexts and an integer representation, the >>> mapping >>> being stored/indexed inside the DBMS. This gives me a small storage >>> overhead >>> with a fixed size. >> >> I don't have a problem with internal mapping like that. > > In SE-PostgreSQL, it maintains own internal mapping between text > represented > security context and its integer identifier. The 'pg_security' system > catalog > stores the pair of them. > > Any tuple (including system catalog) has its security context. It is > stored > within padding area of HeapTupleHeader as an integer value, and it > means the > primary key of 'pg_security' system catalog. > > It also enables to boost userspace AVC, because this idea makes > possible to > implement it using a relationship between identifiers (not a text > representation). > > > When the security policy is reloaded and it makes invalidate the > stored context, > the stored one is dealt as 'unlabeled_t'. > >> But, don't we already have sepostgresql? Maybe you should be looking >> to see if that fits your needs or you might get ideas from the work >> that they performed? > > FYI: > http://code.google.com/p/sepgsql/ > > Andrew, what is your intended base RDBMS? > > Currently, SE-PostgreSQL is the only SELinux awared RDBMS. > It is now under reviewing for the next release (v8.4) cycle. > http://wiki.postgresql.org/wiki/CommitFest:2008-07 > > However, I think we can apply SELinux for any other relational model > implementation. > > Thanks, --------------060002060100020809070400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the information. I have previously looked at the SE-PostgreSQL code/documentation. It was helpful and most interesting. The base DBMS I am using is called Trusted RUBIX, which is an CC EAL-4 (Trusted Solaris) evaluated MLS DBMS. We have been contracted to integrate SELinux TE and MLS (Red Hat flavor) into our DBMS. So, obviously using SE-PostgreSQL is not an option :-) In the bigger picture, this current work is a small (and rather detached) step towards a high robustness (EAL-6+) DBMS solution.

Historically, our company (and myself personally) have been involved in high(er) assurance MLS DBMS products/research for a number of years. As such, we tend to use a more "traditional" minimized trust, reference monitor architecture as opposed to inserting hooks and using query modification for our security enforcement. This means, for instance, that a label object permeates much of our kernel code at a fairly low level as well as storage objects. Thus, the runtime and storage representation must be chosen carefully as it will touch much of our kernel code. We also support full polyinstantiation of named objects, which dictates an efficient label mechanism. (Integration of TE + MLS into traditional MLS polyinstantiation behavior is an interesting topic!)

Out of curiosity, KaiGai, a question about how SE-PostgreSQL presents the security context to a user. From your security guide I see that the context is a selectable column. But, what SQL type is the column? For instance, do you define your own SQL type, such as "Security Context" or is it a VARCHAR that has special constraints placed upon it to force it to conform to the structure of a security context?

Blessings,

Andy

KaiGai Kohei wrote:

I have also considered maintaining my own internal, persistent mapping
between string based contexts and an integer representation, the mapping
being stored/indexed inside the DBMS. This gives me a small storage overhead
with a fixed size.

I don't have a problem with internal mapping like that.

In SE-PostgreSQL, it maintains own internal mapping between text represented
security context and its integer identifier. The 'pg_security' system catalog
stores the pair of them.

Any tuple (including system catalog) has its security context. It is stored
within padding area of HeapTupleHeader as an integer value, and it means the
primary key of 'pg_security' system catalog.

It also enables to boost userspace AVC, because this idea makes possible to
implement it using a relationship between identifiers (not a text representation).

When the security policy is reloaded and it makes invalidate the stored context,
the stored one is dealt as 'unlabeled_t'.

But, don't we already have sepostgresql? Maybe you should be looking
to see if that fits your needs or you might get ideas from the work
that they performed?

FYI:
http://code.google.com/p/sepgsql/

Andrew, what is your intended base RDBMS?

Currently, SE-PostgreSQL is the only SELinux awared RDBMS.
It is now under reviewing for the next release (v8.4) cycle.
http://wiki.postgresql.org/wiki/CommitFest:2008-07

However, I think we can apply SELinux for any other relational model implementation.

Thanks,

--------------060002060100020809070400-- -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MBDRHv015615 for ; Tue, 22 Jul 2008 07:13:27 -0400 Received: from tyo202.gate.nec.co.jp (jazzdrum.ncsc.mil [144.51.5.7]) by zombie.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MBDPfY026920 for ; Tue, 22 Jul 2008 11:13:26 GMT Message-ID: <4885C0D0.7020000@ak.jp.nec.com> Date: Tue, 22 Jul 2008 20:13:20 +0900 From: KaiGai Kohei MIME-Version: 1.0 To: Andrew Warner CC: Eric Paris , selinux@tycho.nsa.gov Subject: Re: questions about persistent storage of security contexts References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <48853AA5.3040607@ak.jp.nec.com> <4885B8EB.9040809@rubix.com> In-Reply-To: <4885B8EB.9040809@rubix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov Andrew Warner wrote: > Thanks for the information. I have previously looked at the > SE-PostgreSQL code/documentation. It was helpful and most interesting. > The base DBMS I am using is called Trusted RUBIX, which is an CC EAL-4 > (Trusted Solaris) evaluated MLS DBMS. We have been contracted to > integrate SELinux TE and MLS (Red Hat flavor) into our DBMS. So, > obviously using SE-PostgreSQL is not an option :-) In the bigger > picture, this current work is a small (and rather detached) step towards > a high robustness (EAL-6+) DBMS solution. It's so amazing! > Historically, our company (and myself personally) have been involved in > high(er) assurance MLS DBMS products/research for a number of years. As > such, we tend to use a more "traditional" minimized trust, reference > monitor architecture as opposed to inserting hooks and using query > modification for our security enforcement. This means, for instance, > that a label object permeates much of our kernel code at a fairly low > level as well as storage objects. Thus, the runtime and storage > representation must be chosen carefully as it will touch much of our > kernel code. We also support full polyinstantiation of named objects, > which dictates an efficient label mechanism. (Integration of TE + MLS > into traditional MLS polyinstantiation behavior is an interesting topic!) I have considered the way to implement polyinstantiation database for any object (including rows) on SE-PostgreSQL, but there were several difficult matters. Especially, it is a tough work to keep PK/FK integrities when security policy is reloaded... > Out of curiosity, KaiGai, a question about how SE-PostgreSQL presents > the security context to a user. From your security guide I see that the > context is a selectable column. But, what SQL type is the column? For > instance, do you define your own SQL type, such as "Security Context" or > is it a VARCHAR that has special constraints placed upon it to force it > to conform to the structure of a security context? In the latest version, the "security_context" system column is declared as TEXT type. Users can give their input as a normal text, then SE-PostgreSQL translate it into internal integer value just before actuall INSERT/UPDATE. Thus, we can describe the following SQL, using operators for TEXT type. :-) SELECT security_context || ':s0:c' || id AS security_context, id, name, price INTO new_tbl FROM old_tbl WHERE id < 256; Thanks, > Blessings, > > Andy > > KaiGai Kohei wrote: >>>> I have also considered maintaining my own internal, persistent mapping >>>> between string based contexts and an integer representation, the >>>> mapping >>>> being stored/indexed inside the DBMS. This gives me a small storage >>>> overhead >>>> with a fixed size. >>> >>> I don't have a problem with internal mapping like that. >> >> In SE-PostgreSQL, it maintains own internal mapping between text >> represented >> security context and its integer identifier. The 'pg_security' system >> catalog >> stores the pair of them. >> >> Any tuple (including system catalog) has its security context. It is >> stored >> within padding area of HeapTupleHeader as an integer value, and it >> means the >> primary key of 'pg_security' system catalog. >> >> It also enables to boost userspace AVC, because this idea makes >> possible to >> implement it using a relationship between identifiers (not a text >> representation). >> >> >> When the security policy is reloaded and it makes invalidate the >> stored context, >> the stored one is dealt as 'unlabeled_t'. >> >>> But, don't we already have sepostgresql? Maybe you should be looking >>> to see if that fits your needs or you might get ideas from the work >>> that they performed? >> >> FYI: >> http://code.google.com/p/sepgsql/ >> >> Andrew, what is your intended base RDBMS? >> >> Currently, SE-PostgreSQL is the only SELinux awared RDBMS. >> It is now under reviewing for the next release (v8.4) cycle. >> http://wiki.postgresql.org/wiki/CommitFest:2008-07 >> >> However, I think we can apply SELinux for any other relational model >> implementation. >> >> Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MBYtmj019654 for ; Tue, 22 Jul 2008 07:34:55 -0400 Received: from house.lunarmania.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MBYsgM009340 for ; Tue, 22 Jul 2008 11:34:54 GMT Message-ID: <4885C5C5.4000108@rubix.com> Date: Tue, 22 Jul 2008 13:34:29 +0200 From: Andy Warner MIME-Version: 1.0 To: KaiGai Kohei CC: Eric Paris , selinux@tycho.nsa.gov Subject: Re: questions about persistent storage of security contexts References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <48853AA5.3040607@ak.jp.nec.com> <4885B8EB.9040809@rubix.com> <4885C0D0.7020000@ak.jp.nec.com> In-Reply-To: <4885C0D0.7020000@ak.jp.nec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov KaiGai Kohei wrote: > Andrew Warner wrote: >> Thanks for the information. I have previously looked at the >> SE-PostgreSQL code/documentation. It was helpful and most >> interesting. The base DBMS I am using is called Trusted RUBIX, which >> is an CC EAL-4 (Trusted Solaris) evaluated MLS DBMS. We have been >> contracted to integrate SELinux TE and MLS (Red Hat flavor) into our >> DBMS. So, obviously using SE-PostgreSQL is not an option :-) In the >> bigger picture, this current work is a small (and rather detached) >> step towards a high robustness (EAL-6+) DBMS solution. > > It's so amazing! > >> Historically, our company (and myself personally) have been involved >> in high(er) assurance MLS DBMS products/research for a number of >> years. As such, we tend to use a more "traditional" minimized trust, >> reference monitor architecture as opposed to inserting hooks and >> using query modification for our security enforcement. This means, >> for instance, that a label object permeates much of our kernel code >> at a fairly low level as well as storage objects. Thus, the runtime >> and storage representation must be chosen carefully as it will touch >> much of our kernel code. We also support full polyinstantiation of >> named objects, which dictates an efficient label mechanism. >> (Integration of TE + MLS into traditional MLS polyinstantiation >> behavior is an interesting topic!) > > I have considered the way to implement polyinstantiation database for > any object (including rows) on SE-PostgreSQL, but there were several > difficult matters. > > Especially, it is a tough work to keep PK/FK integrities when security > policy is reloaded... Yes, PK/FK is one of the more difficult areas of integrating a MAC policy into a traditional RDBMS. In the end I have found that you must make compromises between the PK/FK integrity and MAC security. You simply can't have all of both. Generally, you must compromise the integrity constraint and keep the MAC enforcement. Or, at least remove any high bandwidth channels that infer values of objects which the MAC policy disallows viewing. Polyinstantiation helps, but also raises some interesting issues like which version of a polyinstantiated object should be presented to a user and which objects you want to polyinstantiate. Full polyinstantiation of tables, catalogs, etc can make the view of the data model overly dynamic and confusing. If you do not provide full polyinstantiation then you are allowing covert information flows in violation of the MAC policy. Being the newbie is SELinux that I am :-), I do not understand why the security policy being reloaded makes PK/FK integrity especially tough work. Could you expand on that a little? (I am not even sure I fully understand what happens when a security policy is "reloaded.) Blessings, Andy > >> Out of curiosity, KaiGai, a question about how SE-PostgreSQL presents >> the security context to a user. From your security guide I see that >> the context is a selectable column. But, what SQL type is the column? >> For instance, do you define your own SQL type, such as "Security >> Context" or is it a VARCHAR that has special constraints placed upon >> it to force it to conform to the structure of a security context? > > In the latest version, the "security_context" system column is declared > as TEXT type. Users can give their input as a normal text, then > SE-PostgreSQL > translate it into internal integer value just before actuall > INSERT/UPDATE. > > Thus, we can describe the following SQL, using operators for TEXT > type. :-) > > SELECT security_context || ':s0:c' || id AS security_context, id, > name, price > INTO new_tbl FROM old_tbl WHERE id < 256; > > Thanks, > >> Blessings, >> >> Andy >> >> KaiGai Kohei wrote: >>>>> I have also considered maintaining my own internal, persistent >>>>> mapping >>>>> between string based contexts and an integer representation, the >>>>> mapping >>>>> being stored/indexed inside the DBMS. This gives me a small >>>>> storage overhead >>>>> with a fixed size. >>>> >>>> I don't have a problem with internal mapping like that. >>> >>> In SE-PostgreSQL, it maintains own internal mapping between text >>> represented >>> security context and its integer identifier. The 'pg_security' >>> system catalog >>> stores the pair of them. >>> >>> Any tuple (including system catalog) has its security context. It is >>> stored >>> within padding area of HeapTupleHeader as an integer value, and it >>> means the >>> primary key of 'pg_security' system catalog. >>> >>> It also enables to boost userspace AVC, because this idea makes >>> possible to >>> implement it using a relationship between identifiers (not a text >>> representation). >>> >>> >>> When the security policy is reloaded and it makes invalidate the >>> stored context, >>> the stored one is dealt as 'unlabeled_t'. >>> >>>> But, don't we already have sepostgresql? Maybe you should be looking >>>> to see if that fits your needs or you might get ideas from the work >>>> that they performed? >>> >>> FYI: >>> http://code.google.com/p/sepgsql/ >>> >>> Andrew, what is your intended base RDBMS? >>> >>> Currently, SE-PostgreSQL is the only SELinux awared RDBMS. >>> It is now under reviewing for the next release (v8.4) cycle. >>> http://wiki.postgresql.org/wiki/CommitFest:2008-07 >>> >>> However, I think we can apply SELinux for any other relational model >>> implementation. >>> >>> Thanks, > > -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie.ncsc.mil (zombie.ncsc.mil [144.51.88.131]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MBweO9024498 for ; Tue, 22 Jul 2008 07:58:40 -0400 Received: from house.lunarmania.com (jazzdrum.ncsc.mil [144.51.5.7]) by zombie.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MBwdfY011025 for ; Tue, 22 Jul 2008 11:58:39 GMT Message-ID: <4885CB56.9010700@rubix.com> Date: Tue, 22 Jul 2008 13:58:14 +0200 From: Andy Warner MIME-Version: 1.0 To: Stephen Smalley CC: Eric Paris , selinux@tycho.nsa.gov Subject: Re: questions about persistent storage of security contexts References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <1216692067.17786.21.camel@sulphur> In-Reply-To: <1216692067.17786.21.camel@sulphur> Content-Type: multipart/alternative; boundary="------------040701090806030204050500" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------040701090806030204050500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the info, all is now clear! One more question (from an SELinux newbie!) that has been nagging away at me in regards to the MLS portion of the security context. In the MLS label we have the sensitivity (s0, s1, etc) and the category (c0, c2, etc). Now, as for the categories, its seems clear that in order for label1 to (potentially) dominate label2, then label1 must contain all the categories contained in label2 (i.e., *:c1,c3 can potentially dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are just names of categories and the only relationship between them is equality or non-equality. But with the sensitivity we have an ordering relationship, e.g., s3 is greater than (or higher, or strictly dominates) s1. The numbering applied to the sensitivity seems to imply (or define?) what that ordering is (s3 is greater than s1 because 3 is greater than 1). Is this numerical ordering a fixed part of the SELinux MLS policy or are the sensitivities simply "names" and how the policy is written defines the ordering. That is, is it possible for a configuration of SELinux MLS to have s0 strictly dominate s3? My reason for asking is, if the "numerical ordering" of the sensitivities is always true then I can easily write my own functions to perform dominance checks of the MLS labels and those functions do not need to consult the SELinux API. If the sensitivities are just "names" and the policy instance can define any ordering relationship, then any functions written to perform dominance checks must call the SELinux API and seem non-trivial because no dominance check (only) API is provided and the TE behavior will somehow need to be "filtered" from the security check result. Blessings, Andy Stephen Smalley wrote: > On Mon, 2008-07-21 at 20:35 -0400, Eric Paris wrote: > >> On Mon, Jul 21, 2008 at 7:10 PM, Andrew Warner wrote: >> >>> Hello, >>> >>> I am currently developing an "SELinux aware" DBMS (primarily TE and MLS) >>> that is characterized by: >>> >>> 1. The need to store a security context (in some recoverable form) in our >>> persistent database (storage size of the context is an important factor) >>> 2. The need to frequently perform a high number of security access checks in >>> a performance sensitive way >>> >>> My question relates to the first characteristic from above. I am having >>> trouble deciding on the best way to store the security context in the >>> database. From my research I see (I think!) three different representations >>> for a security context: 1) string; 2) raw; 3) SID. >>> >>> The string representation, generally, seems clear as this is what is shown >>> in all documentation as the context representation that exists in user >>> space. My only question regarding the string representation is: is there is >>> any hard limit to the length of the security context string? Do I need to >>> allow for no theoretical size limit on a context string if I choose to store >>> it? >>> >> No hard limit that I can think of. There might be one somewhere but I >> wouldn't count on it. >> > > Correct - the core logic imposes no fixed limits on the context strings, > although the kernel interfaces do impose certain practical limits (e.g. > page size). The NFSv4 support will likewise impose certain limits in > accordance with existing limits on the size of containing structures. > > >>> I am inferring the the raw representation exists from seeing *_raw functions >>> (e.g., security_compute_create_raw) referenced in selinux header files. >>> Other than seeing these functions declared I am having trouble finding out >>> much about a raw representation. Is there any advantage to >>> storing/manipulating a context in its raw representation? That is, are they >>> more suited for a fast security access check, are they smaller in size, or >>> do they have a fixed or maximum length? >>> >> The _raw is actually what you want. _raw basically just means strings >> without any translations from things like mcstransd. Given a context >> like user_u:role_r:type_t the "raw" on an MLS system maybe >> "user_u:object_r:type_t::s0." Throwing a context with the MLS portion >> attched at the !raw functions will work just fine. >> >> >>> The SID I have also seen mentioned in various documentations but can >>> determine little about them. My guess is that they are an integer value that >>> is used for fast internal access, particularly for the AVC. Are SIDs indeed >>> integer values? Are they persistent or are they meaningful only for a >>> particular OS session? >>> >> That's exactly what they are. They are kernel internal integer >> representations that are (for the most part) only meaningful for that >> session. There are some 'initial sids' that are always the same, but >> no userspace app should care about 'sids' in the general sense. >> >> >>> I have also considered maintaining my own internal, persistent mapping >>> between string based contexts and an integer representation, the mapping >>> being stored/indexed inside the DBMS. This gives me a small storage overhead >>> with a fixed size. >>> >> I don't have a problem with internal mapping like that. >> > > The original SELinux filesystem labeling implementation used something > like that - they were called "persistent security identifiers" (PSIDs), > and were maintained as private indices per-filesystem that mapped to > security context strings. > > >> But, don't we already have sepostgresql? Maybe you should be looking >> to see if that fits your needs or you might get ideas from the work >> that they performed? >> > > Yes, I'd recommend looking at SE-PostgreSQL as a worked example of > applying the Flask architecture to a DBMS, including not only its > approach to storing security contexts but also its approach to the > userspace AVC. You can find a link to that work from the Related Work > page off of the SELinux web site. > > > > -- > 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. > > --------------040701090806030204050500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks for the info, all is now clear!

One more question (from an SELinux newbie!) that has been nagging away at me in regards to the MLS portion of the security context. In the MLS label we have the sensitivity (s0, s1, etc) and the category (c0, c2, etc). Now, as for the categories, its seems clear that in order for label1 to (potentially) dominate label2, then label1 must contain all the categories contained in label2 (i.e., *:c1,c3 can potentially dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are just names of categories and the only relationship between them is equality or non-equality.

But with the sensitivity we have an ordering relationship, e.g., s3 is greater than (or higher, or strictly dominates) s1. The numbering applied to the sensitivity seems to imply (or define?) what that ordering is (s3 is greater than s1 because 3 is greater than 1). Is this numerical ordering a fixed part of the SELinux MLS policy or are the sensitivities simply "names" and how the policy is written defines the ordering. That is, is it possible for a configuration of SELinux MLS to have s0 strictly dominate s3?

My reason for asking is, if the "numerical ordering" of the sensitivities is always true then I can easily write my own functions to perform dominance checks of the MLS labels and those functions do not need to consult the SELinux API. If the sensitivities are just "names" and the policy instance can define any ordering relationship, then any functions written to perform dominance checks must call the SELinux API and seem non-trivial because no dominance check (only) API is provided and the TE behavior will somehow need to be "filtered" from the security check result.

Blessings,

Andy

Stephen Smalley wrote:

On Mon, 2008-07-21 at 20:35 -0400, Eric Paris wrote:

On Mon, Jul 21, 2008 at 7:10 PM, Andrew Warner <warner@rubix.com> wrote:

Hello,

I am currently developing an "SELinux aware" DBMS (primarily TE and MLS)
that is characterized by:

1. The need to store a security context (in some recoverable form) in our
persistent database (storage size of the context is an important factor)
2. The need to frequently perform a high number of security access checks in
a performance sensitive way

My question relates to the first characteristic from above. I am having
trouble deciding on the best way to store the security context in the
database. From my research I  see (I think!) three different representations
for a security context: 1) string; 2) raw; 3) SID.

The string representation, generally, seems clear as this is what is shown
in all documentation as the context representation that exists in user
space. My only question regarding the string representation is: is there is
any hard limit to the length of the security context string? Do I need to
allow for no theoretical size limit on a context string if I choose to store
it?

No hard limit that I can think of. There might be one somewhere but I
wouldn't count on it.


Correct - the core logic imposes no fixed limits on the context strings,
although the kernel interfaces do impose certain practical limits (e.g.
page size).  The NFSv4 support will likewise impose certain limits in
accordance with existing limits on the size of containing structures.

I am inferring the the raw representation exists from seeing *_raw functions
(e.g., security_compute_create_raw) referenced in selinux header files.
Other than seeing these functions declared I am having trouble finding out
much about a raw representation. Is there any advantage to
storing/manipulating a context in its raw representation? That is, are they
more suited for a fast security access check, are they smaller in size, or
do they have a fixed or maximum length?

The _raw is actually what you want.  _raw basically just means strings
without any translations from things like mcstransd.  Given a context
like user_u:role_r:type_t the "raw" on an MLS system maybe
"user_u:object_r:type_t::s0."  Throwing a context with the MLS portion
attched at the !raw functions will work just fine.

The SID I have also seen mentioned in various documentations but can
determine little about them. My guess is that they are an integer value that
is used for fast internal access, particularly for the AVC. Are SIDs indeed
integer values? Are they persistent or are they meaningful only for a
particular OS session?

That's exactly what they are.  They are kernel internal integer
representations that are (for the most part) only meaningful for that
session.  There are some 'initial sids' that are always the same, but
no userspace app should care about 'sids' in the general sense.

I have also considered maintaining my own internal, persistent mapping
between string based contexts and an integer representation, the mapping
being stored/indexed inside the DBMS. This gives me a small storage overhead
with a fixed size.

I don't have a problem with internal mapping like that.


The original SELinux filesystem labeling implementation used something
like that - they were called "persistent security identifiers" (PSIDs),
and were maintained as private indices per-filesystem that mapped to
security context strings.

But, don't we already have sepostgresql?  Maybe you should be looking
to see if that fits your needs or you might get ideas from the work
that they performed?


Yes, I'd recommend looking at SE-PostgreSQL as a worked example of
applying the Flask architecture to a DBMS, including not only its
approach to storing security contexts but also its approach to the
userspace AVC.  You can find a link to that work from the Related Work
page off of the SELinux web site.



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

--------------040701090806030204050500-- -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MCXWW8030885 for ; Tue, 22 Jul 2008 08:33:32 -0400 Received: from py-out-1112.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MCXUHb027195 for ; Tue, 22 Jul 2008 12:33:31 GMT Received: by py-out-1112.google.com with SMTP id a78so5136997pyh.32 for ; Tue, 22 Jul 2008 05:33:30 -0700 (PDT) Subject: Re: questions about persistent storage of security contexts From: Stephen Smalley To: Andy Warner Cc: Eric Paris , selinux@tycho.nsa.gov In-Reply-To: <4885CB56.9010700@rubix.com> References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <1216692067.17786.21.camel@sulphur> <4885CB56.9010700@rubix.com> Content-Type: text/plain Date: Tue, 22 Jul 2008 08:32:29 -0400 Message-Id: <1216729949.3500.5.camel@sulphur> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Tue, 2008-07-22 at 13:58 +0200, Andy Warner wrote: > > Thanks for the info, all is now clear! > > One more question (from an SELinux newbie!) that has been nagging away > at me in regards to the MLS portion of the security context. In the > MLS label we have the sensitivity (s0, s1, etc) and the category (c0, > c2, etc). Now, as for the categories, its seems clear that in order > for label1 to (potentially) dominate label2, then label1 must contain > all the categories contained in label2 (i.e., *:c1,c3 can potentially > dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are > just names of categories and the only relationship between them is > equality or non-equality. > > But with the sensitivity we have an ordering relationship, e.g., s3 is > greater than (or higher, or strictly dominates) s1. The numbering > applied to the sensitivity seems to imply (or define?) what that > ordering is (s3 is greater than s1 because 3 is greater than 1). Is > this numerical ordering a fixed part of the SELinux MLS policy or are > the sensitivities simply "names" and how the policy is written defines > the ordering. That is, is it possible for a configuration of SELinux > MLS to have s0 strictly dominate s3? Yes - they are just names and the dominance relationship is defined by the policy configuration. Computing dominance has been handled in a couple of different ways in the past: 1) Model it as a permission check, with a MLS constraint defined on the permission and allowing the type relationship. 2) Introduce an interface to the kernel security server to provide dominance computations. See the mailing list archives for more discussion. > > My reason for asking is, if the "numerical ordering" of the > sensitivities is always true then I can easily write my own functions > to perform dominance checks of the MLS labels and those functions do > not need to consult the SELinux API. If the sensitivities are just > "names" and the policy instance can define any ordering relationship, > then any functions written to perform dominance checks must call the > SELinux API and seem non-trivial because no dominance check (only) API > is provided and the TE behavior will somehow need to be "filtered" > from the security check result. -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MEV72S018272 for ; Tue, 22 Jul 2008 10:31:08 -0400 Received: from house.lunarmania.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MEV6Hb026818 for ; Tue, 22 Jul 2008 14:31:07 GMT Message-ID: <4885EF10.2010506@rubix.com> Date: Tue, 22 Jul 2008 16:30:40 +0200 From: Andy Warner MIME-Version: 1.0 To: Stephen Smalley CC: Eric Paris , selinux@tycho.nsa.gov Subject: Re: questions about persistent storage of security contexts References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <1216692067.17786.21.camel@sulphur> <4885CB56.9010700@rubix.com> <1216729949.3500.5.camel@sulphur> In-Reply-To: <1216729949.3500.5.camel@sulphur> Content-Type: multipart/alternative; boundary="------------010807000203070200010200" Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov This is a multi-part message in MIME format. --------------010807000203070200010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stephen Smalley wrote: > On Tue, 2008-07-22 at 13:58 +0200, Andy Warner wrote: > >> Thanks for the info, all is now clear! >> >> One more question (from an SELinux newbie!) that has been nagging away >> at me in regards to the MLS portion of the security context. In the >> MLS label we have the sensitivity (s0, s1, etc) and the category (c0, >> c2, etc). Now, as for the categories, its seems clear that in order >> for label1 to (potentially) dominate label2, then label1 must contain >> all the categories contained in label2 (i.e., *:c1,c3 can potentially >> dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are >> just names of categories and the only relationship between them is >> equality or non-equality. >> >> But with the sensitivity we have an ordering relationship, e.g., s3 is >> greater than (or higher, or strictly dominates) s1. The numbering >> applied to the sensitivity seems to imply (or define?) what that >> ordering is (s3 is greater than s1 because 3 is greater than 1). Is >> this numerical ordering a fixed part of the SELinux MLS policy or are >> the sensitivities simply "names" and how the policy is written defines >> the ordering. That is, is it possible for a configuration of SELinux >> MLS to have s0 strictly dominate s3? >> > > Yes - they are just names and the dominance relationship is defined by > the policy configuration. > > Computing dominance has been handled in a couple of different ways in > the past: > 1) Model it as a permission check, with a MLS constraint defined on the > permission and allowing the type relationship. > 2) Introduce an interface to the kernel security server to provide > dominance computations. > > See the mailing list archives for more discussion. > > Is there any requirement that the MLS policy be Bell-LaPadula ? Or can it contain arbitrary information flows? (I am guessing the latter). If not BL, then does that make dominance relationships only something that can be determined for a subset of policy instances? I am assuming the LSPP evaluation uses a BL policy instance (?). Thanks again for the info! >> My reason for asking is, if the "numerical ordering" of the >> sensitivities is always true then I can easily write my own functions >> to perform dominance checks of the MLS labels and those functions do >> not need to consult the SELinux API. If the sensitivities are just >> "names" and the policy instance can define any ordering relationship, >> then any functions written to perform dominance checks must call the >> SELinux API and seem non-trivial because no dominance check (only) API >> is provided and the TE behavior will somehow need to be "filtered" >> from the security check result. >> > > > > > -- > 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. > > --------------010807000203070200010200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Stephen Smalley wrote:

On Tue, 2008-07-22 at 13:58 +0200, Andy Warner wrote:

Thanks for the info, all is now clear!

One more question (from an SELinux newbie!) that has been nagging away
at me in regards to the MLS portion of the security context. In the
MLS label we have the sensitivity (s0, s1, etc) and the category (c0,
c2, etc). Now, as for the categories, its seems clear that in order
for label1 to (potentially) dominate label2, then label1 must contain
all the categories contained in label2 (i.e., *:c1,c3 can potentially
dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are
just names of categories and the only relationship between them is
equality or non-equality.

But with the sensitivity we have an ordering relationship, e.g., s3 is
greater than (or higher, or strictly dominates) s1. The numbering
applied to the sensitivity seems to imply (or define?) what that
ordering is (s3 is greater than s1 because 3 is greater than 1). Is
this numerical ordering a fixed part of the SELinux MLS policy or are
the sensitivities simply "names" and how the policy is written defines
the ordering. That is, is it possible for a configuration of SELinux
MLS to have s0 strictly dominate s3?


Yes - they are just names and the dominance relationship is defined by
the policy configuration.

Computing dominance has been handled in a couple of different ways in
the past:
1) Model it as a permission check, with a MLS constraint defined on the
permission and allowing the type relationship.
2) Introduce an interface to the kernel security server to provide
dominance computations.

See the mailing list archives for more discussion.

Is there any requirement that the MLS policy be Bell-LaPadula ? Or can it contain arbitrary information flows? (I am guessing the latter). If not BL, then does that make dominance relationships only something that can be determined for a subset of policy instances? I am assuming the LSPP evaluation uses a BL policy instance (?).

Thanks again for the info!

My reason for asking is, if the "numerical ordering" of the
sensitivities is always true then I can easily write my own functions
to perform dominance checks of the MLS labels and those functions do
not need to consult the SELinux API. If the sensitivities are just
"names" and the policy instance can define any ordering relationship,
then any functions written to perform dominance checks must call the
SELinux API and seem non-trivial because no dominance check (only) API
is provided and the TE behavior will somehow need to be "filtered"
from the security check result.





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

--------------010807000203070200010200-- -- 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 mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mummy.ncsc.mil (mummy.ncsc.mil [144.51.88.129]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id m6MF9aQY025549 for ; Tue, 22 Jul 2008 11:09:37 -0400 Received: from py-out-1112.google.com (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id m6MF9aHb006383 for ; Tue, 22 Jul 2008 15:09:36 GMT Received: by py-out-1112.google.com with SMTP id a78so5347114pyh.32 for ; Tue, 22 Jul 2008 08:09:35 -0700 (PDT) Subject: Re: questions about persistent storage of security contexts From: Stephen Smalley To: Andy Warner Cc: Eric Paris , selinux@tycho.nsa.gov In-Reply-To: <4885EF10.2010506@rubix.com> References: <48851770.5020002@rubix.com> <7e0fb38c0807211735w40e6fe4bjb31171b9d13cea45@mail.gmail.com> <1216692067.17786.21.camel@sulphur> <4885CB56.9010700@rubix.com> <1216729949.3500.5.camel@sulphur> <4885EF10.2010506@rubix.com> Content-Type: text/plain Date: Tue, 22 Jul 2008 11:08:16 -0400 Message-Id: <1216739298.6659.4.camel@sulphur> Mime-Version: 1.0 Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Tue, 2008-07-22 at 16:30 +0200, Andy Warner wrote: > > > Stephen Smalley wrote: > > On Tue, 2008-07-22 at 13:58 +0200, Andy Warner wrote: > > > > > Thanks for the info, all is now clear! > > > > > > One more question (from an SELinux newbie!) that has been nagging away > > > at me in regards to the MLS portion of the security context. In the > > > MLS label we have the sensitivity (s0, s1, etc) and the category (c0, > > > c2, etc). Now, as for the categories, its seems clear that in order > > > for label1 to (potentially) dominate label2, then label1 must contain > > > all the categories contained in label2 (i.e., *:c1,c3 can potentially > > > dominate *:c3 where as *:c1 can never dominate *:c3). c0, c1, etc are > > > just names of categories and the only relationship between them is > > > equality or non-equality. > > > > > > But with the sensitivity we have an ordering relationship, e.g., s3 is > > > greater than (or higher, or strictly dominates) s1. The numbering > > > applied to the sensitivity seems to imply (or define?) what that > > > ordering is (s3 is greater than s1 because 3 is greater than 1). Is > > > this numerical ordering a fixed part of the SELinux MLS policy or are > > > the sensitivities simply "names" and how the policy is written defines > > > the ordering. That is, is it possible for a configuration of SELinux > > > MLS to have s0 strictly dominate s3? > > > > > > > Yes - they are just names and the dominance relationship is defined by > > the policy configuration. > > > > Computing dominance has been handled in a couple of different ways in > > the past: > > 1) Model it as a permission check, with a MLS constraint defined on the > > permission and allowing the type relationship. > > 2) Introduce an interface to the kernel security server to provide > > dominance computations. > > > > See the mailing list archives for more discussion. > > > > > Is there any requirement that the MLS policy be Bell-LaPadula ? Or can > it contain arbitrary information flows? (I am guessing the latter). If > not BL, then does that make dominance relationships only something > that can be determined for a subset of policy instances? I am assuming > the LSPP evaluation uses a BL policy instance (?). The example security server in SELinux implements a combination of RBAC, TE, and (optional) MLS. The MLS policy is oriented toward BLP but the precise restrictions are defined through policy configuration, in particular the policy writer defines a set of MLS constraints on the Flask classes and permissions that establish what relationship must exist between the subject and object in order for the permission to be authorized. Thus, one could use the MLS engine to implement other hierarchical schemes like Biba instead or a variant of BLP. -- 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.