From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <1491594062.20167.4.camel@tycho.nsa.gov> <1491595109.20167.6.camel@tycho.nsa.gov> From: William Roberts Date: Fri, 7 Apr 2017 14:31:30 -0700 Message-ID: Subject: Re: MLS directory label inheritance rules To: Dennis Sherrell Cc: selinux@tycho.nsa.gov, Stephen Smalley , Nick Kralevich Content-Type: multipart/alternative; boundary=001a1145d9765d3613054c9a5920 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --001a1145d9765d3613054c9a5920 Content-Type: text/plain; charset=UTF-8 On Apr 7, 2017 13:16, "Dennis Sherrell" wrote: In a thread ending with Nick Kravelich's contact infirmation, it was written: " If you write top secret data it should stay top secret even if you're writing to a folder that is normally reserved for secret data, or perhaps mixed data. Iirc it uses the MLS of the process when creating the file entry." I disagree. Top Secret data shoud not be written to a folder which was not provisioned for such. You guys are too nuanced at times, it was meant to be a very simple contrived answer without typing a long diatribe. In general Stephens shared tmp example is in essence what I was going for. Allowing persons or processess of lower classification access to "containers" with higher clearance requirements could cause a data spill. Any thoughts as to active handling of such? Dennis Sherrell Sherrell Consulting Bakersfield, California Company #136601 Counter-Terrorism Cybernetic Countermeasure Developer On Fri, Apr 7, 2017, 12:55 PM Stephen Smalley wrote: > On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote: > > On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote: > > > When a file is created in a directory, the default label for the > > > file > > > is based on the label of the enclosing directory (unless something > > > like setfscreatecon is used). For example: > > > > > > bullhead:/ # cd /data/misc/zoneinfo/ > > > > > > bullhead:/data/misc/zoneinfo # ls -ladZ . > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 1971-06-19 17:07 . > > > bullhead:/data/misc/zoneinfo # touch asdf > > > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf > > > > > > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 4096 > > > 2017-04-07 18:32 . > > > -rw-rw-rw- 1 root root u:object_r:zoneinfo_data_file:s0 0 > > > 2017-04-07 18:32 asdf > > > > > > note how the label of the "asdf" file matches the label of the > > > enclosing directory. > > > > > > However, that's not true when the directory uses categories. In > > > that > > > case, the newly created file inherits the label, but not the > > > categories. For example: > > > > > > bullhead:/data/data # cd /data/data/com.android.chrome > > > bullhead:/data/data/com.android.chrome # ls -ladZ . > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 1971-07-15 15:31 . > > > bullhead:/data/data/com.android.chrome # touch asdf > > > bullhead:/data/data/com.android.chrome # ls -laZd . asdf > > > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,c768 > > > 4096 > > > 2017-04-07 18:35 . > > > -rw-rw-rw- 1 > > > root root u:object_r:app_data_file:s0 0 > > > 2017-04-07 18:35 asdf > > > > > > Note how the label is maintained, but the "c512,c768" portion is > > > not > > > maintained. While this example occurs when I'm running in a > > > permissive > > > domain, it also occurs in an enforcing domain. > > > > > > The inconsistency seems weird, and I'm sure there's a good reason > > > why > > > this occurs that I'm not familiar with. Can someone help me > > > understand > > > if this is expected, and if so, why? > > > > First, the good news is that you get to specify which behavior you > > want > > for each context field and object class through policy (as long as > > your > > kernel and policy version supports it), see: > > https://selinuxproject.org/page/DefaultRules > > > > Second, there are different defaults for each of the fields of the > > security contexts based on what is most normative for that particular > > security model. The user identity defaults to that of the creating > > process since we typically do not allow a process to create files > > with > > a different user identity and want the file to reflect its creator > > (this is defined through constraints on user identity in policies > > that > > define more than one, unlike Android). The role defaults to the fixed > > object_r role because originally we didn't envision a use case for > > roles on files. The MLS range defaults to the low/current level of > > the > > process because a process is typically not allowed to create files at > > a > > different level and we want the file to reflect the sensitivity of > > the > > data which originated from the process. The type defaults to a > > related > > object type (in this case that of the parent directory) because > > process > > domains and object types are separate (aside from overlapping use for > > /proc/pid) and the relationships among them are explicit through the > > TE > > rules / access matrix rather than through implicit rules. > > > > Of course, in addition to being able to globally configure the > > default > > behavior, you can also customize specific cases through the > > role/type/range_transition rules. > > > > With your example above, you wanted the file to inherit the level of > > the directory, but consider the situation where a process with > > categories (:s0:c512,c768) creates a file in some shared > > (mlstrustedobject) directory that is just :s0. Do you want that file > > to end up as just :s0? In the MLS world, that would be a downgrade / > > info leak. > > I guess that's not a great example since then the file would also end > up with the same type by default and thus would be a mlstrustedobject > and accessible regardless of its level. So you'd want a type > transition to a derived type for files created in that directory to > avoid that. > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. _______________________________________________ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. --001a1145d9765d3613054c9a5920 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 7, 2017 13:16, "Dennis Sherrell" <sherrellconsulting@gmail.com> w= rote:

In a = thread ending with Nick Kravelich's contact infirmation, it was written= :

"
If you write top secret data it should stay top secret even if you're w= riting to a folder that is normally reserved for secret data, or perhaps mi= xed data. Iirc it uses the MLS of the process when creating the file entry.= "

I disagree. Top Secret data shoud not be written to a = folder which was not provisioned for such.

You guys are too nuanced at times, it was meant to be a= very simple contrived answer without typing a long diatribe. In general St= ephens shared tmp example is in essence what I was going for.=C2=A0


Allowing persons or processess= of lower classification access to "containers" with higher clear= ance requirements could cause a data spill. Any thoughts as to active handl= ing of such?

Dennis Sherrell
Sherrell Consulting
Bakersfield, California Company #136601
Counter-Terrorism
Cybernetic Countermeasure Developer


On Fri, Apr 7, 2017, 12:55 = PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
On Fri, 2017-04-07 at 15:41 -0400, Stephen Smalley wrote:
> On Fri, 2017-04-07 at 11:39 -0700, Nick Kralevich wrote:
> > When a file is created in a directory, the default label for the<= br class=3D"m_-4248203155830866115gmail_msg"> > > file
> > is based on the label of the enclosing directory (unless somethin= g
> > like setfscreatecon is used). For example:
> >
> > bullhead:/ # cd /data/misc/zoneinfo/
> >
> > bullhead:/data/misc/zoneinfo # ls -ladZ .
> > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 = 4096
> > 1971-06-19 17:07 .
> > bullhead:/data/misc/zoneinfo # touch asdf
> > bullhead:/data/misc/zoneinfo # ls -ladZ . asdf
> >
> > drwxrwxr-x 2 system system u:object_r:zoneinfo_data_file:s0 = 4096
> > 2017-04-07 18:32 .
> > -rw-rw-rw- 1 root=C2=A0=C2=A0=C2=A0root=C2=A0=C2=A0=C2=A0u:object= _r:zoneinfo_data_file:s0=C2=A0=C2=A0=C2=A0=C2=A00
> > 2017-04-07 18:32 asdf
> >
> > note how the label of the "asdf" file matches the label= of the
> > enclosing directory.
> >
> > However, that's not true when the directory uses categories. = In
> > that
> > case, the newly created file inherits the label, but not the
> > categories. For example:
> >
> > bullhead:/data/data # cd /data/data/com.android.chrome
> > bullhead:/data/data/com.android.chrome # ls -ladZ .
> > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,= c768
> > 4096
> > 1971-07-15 15:31 .
> > bullhead:/data/data/com.android.chrome # touch asdf
> > bullhead:/data/data/com.android.chrome # ls -laZd . asdf
> > drwx------ 6 u0_a60 u0_a60 u:object_r:app_data_file:s0:c512,= c768
> > 4096
> > 2017-04-07 18:35 .
> > -rw-rw-rw- 1
> > root=C2=A0=C2=A0=C2=A0root=C2=A0=C2=A0=C2=A0u:object_r:app_d= ata_file:s0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A00
> > 2017-04-07 18:35 asdf
> >
> > Note how the label is maintained, but the "c512,c768" p= ortion is
> > not
> > maintained. While this example occurs when I'm running in a > > permissive
> > domain, it also occurs in an enforcing domain.
> >
> > The inconsistency seems weird, and I'm sure there's a goo= d reason
> > why
> > this occurs that I'm not familiar with. Can someone help me > > understand
> > if this is expected, and if so, why?
>
> First, the good news is that you get to specify which behavior you
> want
> for each context field and object class through policy (as long as
> your
> kernel and policy version supports it), see:
> https://s= elinuxproject.org/page/DefaultRules
>
> Second, there are different defaults for each of the fields of the
> security contexts based on what is most normative for that particular<= br class=3D"m_-4248203155830866115gmail_msg"> > security model.=C2=A0 The user identity defaults to that of the creati= ng
> process since we typically do not allow a process to create files
> with
> a different user identity and want the file to reflect its creator
> (this is defined through constraints on user identity in policies
> that
> define more than one, unlike Android). The role defaults to the fixed<= br class=3D"m_-4248203155830866115gmail_msg"> > object_r role because originally we didn't envision a use case for=
> roles on files.=C2=A0=C2=A0The MLS range defaults to the low/current l= evel of
> the
> process because a process is typically not allowed to create files at<= br class=3D"m_-4248203155830866115gmail_msg"> > a
> different level and we want the file to reflect the sensitivity of
> the
> data which originated from the process. The type defaults to a
> related
> object type=C2=A0(in this case that of the parent directory) because > process
> domains and object types are separate (aside from overlapping use for<= br class=3D"m_-4248203155830866115gmail_msg"> > /proc/pid) and the relationships among them are explicit through the > TE
> rules / access matrix rather than through implicit rules.
>
> Of course, in addition to being able to globally configure the
> default
> behavior, you can also customize specific cases through the
> role/type/range_transition rules.
>
> With your example above, you wanted the file to inherit the level of > the directory, but consider the situation where a process with
> categories (:s0:c512,c768) creates a file in some shared
> (mlstrustedobject) directory that is just :s0.=C2=A0=C2=A0Do you want = that file
> to end up as just :s0?=C2=A0=C2=A0In the MLS world, that would be a do= wngrade /
> info leak.

I guess that's not a great example since then the file would also end up with the same type by default and thus would be a mlstrustedobject
and accessible regardless of its level.=C2=A0 So you'd want a type
transition to a derived type for files created in that directory to
avoid that.

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave= @tycho.nsa.gov.
To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

--001a1145d9765d3613054c9a5920--