On 4/7/2017 1:15 PM, 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. 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?
If you can only put TS objects in TS directories where
do you put the first TS directory? While it is generally
true that you don't want to put TS things in places that
uncleared subjects can't see them, you have to allow for
the exception of a TS directory in a less than TS directory.
Otherwise you can only have single-level filesystems.
We ran into this question way back in the Orange Book era.
Although there were several "clever" ideas put forth, the
model of allowing higher level objects to be created in
lower level directories *under controlled circumstances*
was gradually adopted as the only viable option.
Dennis Sherrell
Sherrell Consulting
Bakersfield, California Company #136601
Counter-Terrorism
Cybernetic Countermeasure Developer
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@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
|
