Changing unlabeled_t on files to invalid_label_t.

Changing unlabeled_t on files to invalid_label_t.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We would like to change

sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)

to something like

sid file_labels         gen_context(system_u:object_r:invalid_label_t,s0)

Since explaining to someone that a file without a label is file_t, but if it
has a label that the kernel does not understand it is labeled as unlabeled_t.
A file with a label is unlabeled_t????  While a file without a label is file_t.


#
# unlabeled_t is the type of unlabeled objects.
# Objects that have no known labeling information or that
# have labels that are no longer valid are treated as having this type.
#

#
# file_t is the default type of a file that has not yet been
# assigned an extended attribute (EA) value (when using a filesystem
# that supports EAs).
#

These two type definitions seem to conflict, with file_t winning at least on
systems that support XAttrs.

I would guess a better fix would be to change the kernel to handle the case
where an object is unlabeled_t one way and if it is labeled and the kernel
does not understand the label differently.

sid invalid_file_labels gen_context(system_u:object_r:invalid_label_t,s0)

Opinions....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLPGlMACgkQrlYvE4MpobOrDwCgwSduQpyqjGFni/0dksiv0I2j
uEAAn181YTHYYRj0XSern/+CPtuUp7Vu
=3HJ3
-----END PGP SIGNATURE-----

Re: Changing unlabeled_t on files to invalid_label_t.

[Dominick Grift]

On Thu, 2014-01-09 at 16:53 -0500, Daniel J Walsh wrote:
> We would like to change
> 
> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
> 
> to something like
> 
> sid file_labels         gen_context(system_u:object_r:invalid_label_t,s0)

I think the file_labels isid is deprecated. Do you mean the unlabeled
isid instead?

But yes i think i also suggested this a couple times.

Add a new isid "invalid"

Then leave the unlabeled isid for netlabel ( i think netlabel also uses
the unlabeled isid )

That way we can also get rid of the inconsistency where "unlabeled"
nodes are labeled with the object_r role. (nodes are active entities so
i would argue the system_r role would be more sensible for nodes)

Then maybe while we are at it also see if we can fix that isid ordering
issue. If one in ones policy messes up the ordering of the isid context
specs one gets all kinds of weird behavior.

Maybe we can then also really get rid of those deprecated isids? They've
been marked deprecated for ages, but as soon as you remove them from
policy ; shed hits the fan. 

Re: Changing unlabeled_t on files to invalid_label_t.

[Dominick Grift]

On Thu, 2014-01-09 at 23:21 +0100, Dominick Grift wrote:
> On Thu, 2014-01-09 at 16:53 -0500, Daniel J Walsh wrote:


> Then leave the unlabeled isid for netlabel ( i think netlabel also uses
> the unlabeled isid )
> 
> That way we can also get rid of the inconsistency where "unlabeled"
> nodes are labeled with the object_r role. (nodes are active entities so
> i would argue the system_r role would be more sensible for nodes)

Not sure if it was peers, nodes or both but i know i was a little
annoyed by the inconsistency. I like consistency and intuitiveness.

( on a side note: "system_u:object_r:node_t" is also associated with the
node isid currently, not sure if "system_u:system_r:node_t" would be
more appropriate -- same for netlabel_peer i guess )

> Then maybe while we are at it also see if we can fix that isid ordering
> issue. If one in ones policy messes up the ordering of the isid context
> specs one gets all kinds of weird behavior.

Not the isid contexts specification ordering but the isid declarations
ordering (in the initial_sids file)

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Thu, Jan 9, 2014 at 5:49 PM, Dominick Grift <dominick.grift@gmail.com> wrote:
> On Thu, 2014-01-09 at 23:21 +0100, Dominick Grift wrote:
>> On Thu, 2014-01-09 at 16:53 -0500, Daniel J Walsh wrote:
>> Then leave the unlabeled isid for netlabel ( i think netlabel also uses
>> the unlabeled isid )
>>
>> That way we can also get rid of the inconsistency where "unlabeled"
>> nodes are labeled with the object_r role. (nodes are active entities so
>> i would argue the system_r role would be more sensible for nodes)
>
> Not sure if it was peers, nodes or both but i know i was a little
> annoyed by the inconsistency. I like consistency and intuitiveness.
>
> ( on a side note: "system_u:object_r:node_t" is also associated with the
> node isid currently, not sure if "system_u:system_r:node_t" would be
> more appropriate -- same for netlabel_peer i guess )
>
>> Then maybe while we are at it also see if we can fix that isid ordering
>> issue. If one in ones policy messes up the ordering of the isid context
>> specs one gets all kinds of weird behavior.
>
> Not the isid contexts specification ordering but the isid declarations
> ordering (in the initial_sids file)

In general I'm not opposed to reworking the initial sid bits,
including adding/removing initial sids, but it's pretty low on my
priority list as there are still bugs that need squashing.  I also
haven't dug into the toolchain aspect of the initial sid stuff, that
could change my opinion.

-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Thursday, January 09, 2014 11:21:24 PM Dominick Grift wrote:
> Then leave the unlabeled isid for netlabel ( i think netlabel also uses
> the unlabeled isid )

While NetLabel uses the unlabeled initial sid, there are plenty of other 
places where it is used, the most obvious being almost all the initial object 
allocation functions in the kernel.  Were going to need to keep the unlabeled 
initial sid as "unlabeled_t" or similar for the foreseeable future.
 
-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Eric Paris]

static int superblock_alloc_security(struct super_block *sb)
{
...
         sbsec->def_sid = SECINITSID_FILE;

static int inode_alloc_security(struct inode *inode)
{
        struct inode_security_struct *isec;
...
        isec->sid = SECINITSID_UNLABELED;

static int inode_doinit_with_dentry(struct inode *inode, struct dentry
*opt_dentry)
{
...
        if (rc != -ENODATA) {
                sid = sbsec->def_sid;
...
        if (rc) {
...
                /* Leave with the unlabeled SID */
                rc = 0;
                break;

So there you have it...

I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....

On Thu, Jan 9, 2014 at 5:54 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Thursday, January 09, 2014 11:21:24 PM Dominick Grift wrote:
>> Then leave the unlabeled isid for netlabel ( i think netlabel also uses
>> the unlabeled isid )
>
> While NetLabel uses the unlabeled initial sid, there are plenty of other
> places where it is used, the most obvious being almost all the initial object
> allocation functions in the kernel.  Were going to need to keep the unlabeled
> initial sid as "unlabeled_t" or similar for the foreseeable future.
>
> --
> paul moore
> www.paul-moore.com
>
> _______________________________________________
> 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.

Re: Changing unlabeled_t on files to invalid_label_t.

[Dominick Grift]

On Thu, 2014-01-09 at 18:07 -0500, Eric Paris wrote:

> 
> I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....

For what it is worth ; i would not prefer the name invalid_label

Although it is an accurate name i do not think its optimal, i would go
for "invalid" with the invalid_t type sid associated with it.

Invalid_label can give the impression that the whole context is invalid,
and although the context as a whole is invalid, it is usually only due
to one or more invalid sids (usually just one).

By leaving out the "label" part, you leave less room for
misinterpretation.

Not a big deal i know..

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Thu, Jan 9, 2014 at 6:22 PM, Dominick Grift <dominick.grift@gmail.com> wrote:
> On Thu, 2014-01-09 at 18:07 -0500, Eric Paris wrote:
>>
>> I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....
>
> For what it is worth ; i would not prefer the name invalid_label
>
> Although it is an accurate name i do not think its optimal, i would go
> for "invalid" with the invalid_t type sid associated with it.

I agree, I tend to like SECINITSID_INVALID/invalid/invalid_t a bit more.

> Invalid_label can give the impression that the whole context is invalid,
> and although the context as a whole is invalid, it is usually only due
> to one or more invalid sids (usually just one).

Don't forget that a sid, including the initial sids, represents a full
label/context.

-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Dominick Grift]

On Thu, 2014-01-09 at 19:23 -0500, Paul Moore wrote:

> 
> Don't forget that a sid, including the initial sids, represents a full
> label/context.
> 

Yes sorry, I will try to keep that in mind.

I use the terminology a bit different since i do not look at it from a
code perspective.

To me a sid is just what the name suggests: a security identifier.

user_u -> identity security identifier
role_r -> role security identifier
type_t -> type security identifier
s0 -> sensitivity security identifier
c0 -> compartment security identifier

I guess from that perspective i would probably also refer to for example
traditional uids as sids.

uid=1000(joe)

key/value pairs, were the key ("uid") is a security attribute and the
value (1000/(joe)) is a/are security identifier(s)

I know its probably technically incorrect. I have the same thing with
the term domain.

I use that term in a different context than everyone else. What you call
a domain i call a domain type.

To me a particular domain encapsulates all rules associated with a
particular domain type

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Friday, January 10, 2014 12:52:18 PM Dominick Grift wrote:
> On Thu, 2014-01-09 at 19:23 -0500, Paul Moore wrote:
> > Don't forget that a sid, including the initial sids, represents a full
> > label/context.
> 
> Yes sorry, I will try to keep that in mind.

No worries, the terminology here has always been a bit messy ...

> I use the terminology a bit different since i do not look at it from a
> code perspective.
> 
> To me a sid is just what the name suggests: a security identifier.
> 
> user_u -> identity security identifier
> role_r -> role security identifier
> type_t -> type security identifier
> s0 -> sensitivity security identifier
> c0 -> compartment security identifier

Perhaps this is the difference between someone who works on policy versus 
someone who works with the SELinux code :)

>From my point of view, a security label is pretty much an opaque blob most of 
the time.  While there are different "fields" (what I choose to call the user, 
role, type, and MLS information), security decisions are made based on the 
label as a whole, not individual fields.

I also tend to cringe a bit when I hear the term "sid" used outside the 
context of kernel patch.  A sid is really just a private convenience item used 
by the kernel to make it easier and faster to pass around labels.  In my mind 
the term "sid" should never be used outside kernel patch discussions.

> I guess from that perspective i would probably also refer to for example
> traditional uids as sids.
> 
> uid=1000(joe)

Argh, please no ... we have enough three letter acronyms floating around this 
place, that last thing we want is to start swapping them around! :)

> key/value pairs, were the key ("uid") is a security attribute and the
> value (1000/(joe)) is a/are security identifier(s)

I see your point, but a UID is such a fundamental term and has a widely 
accepted definition, I think calling it a sid is only going to be a problem.

> I know its probably technically incorrect. I have the same thing with
> the term domain.
> 
> I use that term in a different context than everyone else. What you call
> a domain i call a domain type.

Technically a domain is a type ...

> To me a particular domain encapsulates all rules associated with a
> particular domain type

This to me isn't a major difference.  I suppose it is similar to the 
difference between a word itself and what that word represents.

-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Stephen Smalley]

On 01/09/2014 06:07 PM, Eric Paris wrote:
> static int superblock_alloc_security(struct super_block *sb)
> {
> ...
>          sbsec->def_sid = SECINITSID_FILE;
> 
> static int inode_alloc_security(struct inode *inode)
> {
>         struct inode_security_struct *isec;
> ...
>         isec->sid = SECINITSID_UNLABELED;
> 
> static int inode_doinit_with_dentry(struct inode *inode, struct dentry
> *opt_dentry)
> {
> ...
>         if (rc != -ENODATA) {
>                 sid = sbsec->def_sid;
> ...
>         if (rc) {
> ...
>                 /* Leave with the unlabeled SID */
>                 rc = 0;
>                 break;
> 
> So there you have it...
> 
> I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....

Difficult (impossible?) to do in a fully backward compatible manner (to
include the case of loading new policy on old kernel, whether initially
or update/reload on an already running kernel with an older policy).

SECINITSID_NUM is baked into the kernel, as are the indices.
You are more likely to have success by reusing one of the currently
unused initial SIDs for a new purpose, especially as some of them have
never been used in any mainline kernel (some of them predate Linux 2.6.0).

Dynamic initial sid lookup (ala the dynamic class/perm lookup) support
would be nice to have, but at most that will allow us to delete obsolete
initial SIDs from refpolicy, not fix old kernels.

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Friday, January 10, 2014 09:42:42 AM Stephen Smalley wrote:
> On 01/09/2014 06:07 PM, Eric Paris wrote:
> > I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....
> 
> Difficult (impossible?) to do in a fully backward compatible manner (to
> include the case of loading new policy on old kernel, whether initially
> or update/reload on an already running kernel with an older policy).

Do we really need to worry about being able to load new policy into a old 
kernel?  In general I thought the backward compatible issue was that newer 
kernels needed to support older userspace, not the other way around.

-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Stephen Smalley]

On 01/10/2014 09:49 AM, Paul Moore wrote:
> On Friday, January 10, 2014 09:42:42 AM Stephen Smalley wrote:
>> On 01/09/2014 06:07 PM, Eric Paris wrote:
>>> I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....
>>
>> Difficult (impossible?) to do in a fully backward compatible manner (to
>> include the case of loading new policy on old kernel, whether initially
>> or update/reload on an already running kernel with an older policy).
> 
> Do we really need to worry about being able to load new policy into a old 
> kernel?  In general I thought the backward compatible issue was that newer 
> kernels needed to support older userspace, not the other way around.

Well, you'll at least need code in the kernel to handle the case where
the policy does not define any new initial SIDs that you introduce in
the policy, remapping them to e.g. unlabeled or something.

And you likely want to ensure that people don't accidentally load new
policy into old kernel and break things, whether by tying the new
initial SIDS to a policy capability or policy version.

Re: Changing unlabeled_t on files to invalid_label_t.

[Stephen Smalley]

On 01/10/2014 09:56 AM, Stephen Smalley wrote:
> On 01/10/2014 09:49 AM, Paul Moore wrote:
>> On Friday, January 10, 2014 09:42:42 AM Stephen Smalley wrote:
>>> On 01/09/2014 06:07 PM, Eric Paris wrote:
>>>> I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....
>>>
>>> Difficult (impossible?) to do in a fully backward compatible manner (to
>>> include the case of loading new policy on old kernel, whether initially
>>> or update/reload on an already running kernel with an older policy).
>>
>> Do we really need to worry about being able to load new policy into a old 
>> kernel?  In general I thought the backward compatible issue was that newer 
>> kernels needed to support older userspace, not the other way around.
> 
> Well, you'll at least need code in the kernel to handle the case where
> the policy does not define any new initial SIDs that you introduce in
> the policy, remapping them to e.g. unlabeled or something.
> 
> And you likely want to ensure that people don't accidentally load new
> policy into old kernel and break things, whether by tying the new
> initial SIDS to a policy capability or policy version.

But reusing one of the dead initial SIDs might be easier - I think you
have done that previously for some of the networking ones.  Currently
unused ones are:
sid file_labels u:object_r:unlabeled:s0
sid init u:object_r:unlabeled:s0
sid igmp_packet u:object_r:unlabeled:s0
sid icmp_socket u:object_r:unlabeled:s0
sid tcp_socket u:object_r:unlabeled:s0
sid sysctl_modprobe u:object_r:unlabeled:s0
sid sysctl_fs u:object_r:unlabeled:s0
sid sysctl_kernel u:object_r:unlabeled:s0
sid sysctl_net u:object_r:unlabeled:s0
sid sysctl_net_unix u:object_r:unlabeled:s0
sid sysctl_vm u:object_r:unlabeled:s0
sid sysctl_dev u:object_r:unlabeled:s0
sid kmod u:object_r:unlabeled:s0
sid policy u:object_r:unlabeled:s0
sid scmp_packet u:object_r:unlabeled:s0

Some of those were never used in any mainline kernel.
Others were used but ultimately removed.

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Friday, January 10, 2014 11:13:35 AM Stephen Smalley wrote:
> On 01/10/2014 09:56 AM, Stephen Smalley wrote:
> > On 01/10/2014 09:49 AM, Paul Moore wrote:
> >> On Friday, January 10, 2014 09:42:42 AM Stephen Smalley wrote:
> >>> On 01/09/2014 06:07 PM, Eric Paris wrote:
> >>>> I believe we need a new initial sid.  SECINITSID_INVALID_LABEL....
> >>> 
> >>> Difficult (impossible?) to do in a fully backward compatible manner (to
> >>> include the case of loading new policy on old kernel, whether initially
> >>> or update/reload on an already running kernel with an older policy).
> >> 
> >> Do we really need to worry about being able to load new policy into a old
> >> kernel?  In general I thought the backward compatible issue was that
> >> newer
> >> kernels needed to support older userspace, not the other way around.
> > 
> > Well, you'll at least need code in the kernel to handle the case where
> > the policy does not define any new initial SIDs that you introduce in
> > the policy, remapping them to e.g. unlabeled or something.

Yep.

> > And you likely want to ensure that people don't accidentally load new
> > policy into old kernel and break things, whether by tying the new
> > initial SIDS to a policy capability or policy version.

Yep.  I imagine this would be a new policy version, but that is just a gut 
feeling not backed up by any actual inspection or serious thought.

> But reusing one of the dead initial SIDs might be easier - I think you
> have done that previously for some of the networking ones.

Yep, we reused the netmsg initial SID for NetLabel traffic that is missing 
user/role/type information.

For the record, I'm in no hurry to rework the initial SID bits, I just think 
that ultimately they could use some improvement similar to what was done with 
the dynamic class/permissions code.

-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Russell Coker]

On Fri, 10 Jan 2014 09:49:28 Paul Moore wrote:
> Do we really need to worry about being able to load new policy into a old 
> kernel?  In general I thought the backward compatible issue was that newer 
> kernels needed to support older userspace, not the other way around.

Yes.  One case is when you have a Xen server that uses the kernel from the 
Dom0 for the DomUs (which is easier than taking the DomU kernel to the Dom0).

Another case is hardware compatability issues, being able to upgrade all user-
space before dealing with hardware issues is a good option to have.

Finally allowing the possibility of downgrading the kernel in case of 
discovering a bug in the new kernel is a good thing.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Changing unlabeled_t on files to invalid_label_t.

[Ted Toth]

+1

On Thu, Jan 9, 2014 at 3:53 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We would like to change
>
> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
>
> to something like
>
> sid file_labels         gen_context(system_u:object_r:invalid_label_t,s0)
>
> Since explaining to someone that a file without a label is file_t, but if it
> has a label that the kernel does not understand it is labeled as unlabeled_t.
> A file with a label is unlabeled_t????  While a file without a label is file_t.
>
>
> #
> # unlabeled_t is the type of unlabeled objects.
> # Objects that have no known labeling information or that
> # have labels that are no longer valid are treated as having this type.
> #
>
> #
> # file_t is the default type of a file that has not yet been
> # assigned an extended attribute (EA) value (when using a filesystem
> # that supports EAs).
> #
>
> These two type definitions seem to conflict, with file_t winning at least on
> systems that support XAttrs.
>
> I would guess a better fix would be to change the kernel to handle the case
> where an object is unlabeled_t one way and if it is labeled and the kernel
> does not understand the label differently.
>
> sid invalid_file_labels gen_context(system_u:object_r:invalid_label_t,s0)
>
> Opinions....
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLPGlMACgkQrlYvE4MpobOrDwCgwSduQpyqjGFni/0dksiv0I2j
> uEAAn181YTHYYRj0XSern/+CPtuUp7Vu
> =3HJ3
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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.

Re: Changing unlabeled_t on files to invalid_label_t.

[Paul Moore]

On Thursday, January 09, 2014 04:53:23 PM Daniel J Walsh wrote:
> We would like to change
> 
> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
> 
> to something like
> 
> sid file_labels         gen_context(system_u:object_r:invalid_label_t,s0)

Hmmm, this is odd ... I'm quickly grep'ing the kernel source and while I can 
find the file initial sid, I can't seem to find the file_labels initial sid 
used anywhere ...

Are you talking about the file initial sid?

> Since explaining to someone that a file without a label is file_t, but if it
> has a label that the kernel does not understand it is labeled as
> unlabeled_t. A file with a label is unlabeled_t????  While a file without a
> label is file_t.

That is annoying.  I personally think that unlabeled_t is the right choice for 
objects (files, packets, etc.) without any label information.  If there is 
some label present, even if it is invalid (e.g. MLS label on a non-MLS sytem), 
then it should have a different label, invalid_t?

> #
> # unlabeled_t is the type of unlabeled objects.
> # Objects that have no known labeling information or that
> # have labels that are no longer valid are treated as having this type.
> #
> 
> #
> # file_t is the default type of a file that has not yet been
> # assigned an extended attribute (EA) value (when using a filesystem
> # that supports EAs).
> #
> 
> These two type definitions seem to conflict, with file_t winning at least on
> systems that support XAttrs.

If I had to guess I think this might be due to some differences in the file 
initial sid and some default handling with the genfs code.  Eric or Stephen 
can probably explain this better than I can right now.

> I would guess a better fix would be to change the kernel to handle the case
> where an object is unlabeled_t one way and if it is labeled and the kernel
> does not understand the label differently.
> 
> sid invalid_file_labels gen_context(system_u:object_r:invalid_label_t,s0)
> 
> Opinions....

Makes sense to me.  Just two suggestions ... First, I think the MLS field 
should probably be "mls_systemhigh" and not "s0"; while it is different from 
unlabeled_t, I think we want to treat it the same from a MLS perspective.  
Second, make the invalid label a bit more general and not tied just to files, 
e.g. invalid_t, so we could use it for other objects if needed.

sid invalid_label gen_context(system_u:object_r:invalid_t,mls_systemhigh)

-- 
paul moore
www.paul-moore.com

Re: Changing unlabeled_t on files to invalid_label_t.

[Stephen Smalley]

On 01/09/2014 04:53 PM, Daniel J Walsh wrote:
> We would like to change
> 
> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
> 
> to something like
> 
> sid file_labels         gen_context(system_u:object_r:invalid_label_t,s0)
> 
> Since explaining to someone that a file without a label is file_t, but if it
> has a label that the kernel does not understand it is labeled as unlabeled_t.
> A file with a label is unlabeled_t????  While a file without a label is file_t.
> 
> 
> #
> # unlabeled_t is the type of unlabeled objects.
> # Objects that have no known labeling information or that
> # have labels that are no longer valid are treated as having this type.
> #
> 
> #
> # file_t is the default type of a file that has not yet been
> # assigned an extended attribute (EA) value (when using a filesystem
> # that supports EAs).
> #
> 
> These two type definitions seem to conflict, with file_t winning at least on
> systems that support XAttrs.

BTW, if you want to just solve the problem you originally described, you
can do that just by changing policy to assign unlabeled_t to the file
initial SID, and then you'll get unlabeled_t for both.  That's what we
do in the Android policy.

Re: Changing unlabeled_t on files to invalid_label_t.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/10/2014 11:06 AM, Stephen Smalley wrote:
> On 01/09/2014 04:53 PM, Daniel J Walsh wrote:
>> We would like to change
>> 
>> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
>> 
>> to something like
>> 
>> sid file_labels
>> gen_context(system_u:object_r:invalid_label_t,s0)
>> 
>> Since explaining to someone that a file without a label is file_t, but if
>> it has a label that the kernel does not understand it is labeled as
>> unlabeled_t. A file with a label is unlabeled_t????  While a file without
>> a label is file_t.
>> 
>> 
>> # # unlabeled_t is the type of unlabeled objects. # Objects that have no
>> known labeling information or that # have labels that are no longer valid
>> are treated as having this type. #
>> 
>> # # file_t is the default type of a file that has not yet been # assigned
>> an extended attribute (EA) value (when using a filesystem # that supports
>> EAs). #
>> 
>> These two type definitions seem to conflict, with file_t winning at least
>> on systems that support XAttrs.
> 
> BTW, if you want to just solve the problem you originally described, you 
> can do that just by changing policy to assign unlabeled_t to the file 
> initial SID, and then you'll get unlabeled_t for both.  That's what we do
> in the Android policy.
> 
> 
Yes I am thinking about that but then we still have the unlabeled_t when the
object is actually labeled.

Changing file_t to unlabeled_t, then we have to change some interfaces that
deal with file_t to deal with unlabeled_t.

and add an alias for file_t.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLQHBsACgkQrlYvE4MpobO8dQCfaHFiIxD/5My+V1e0oVI9JgAP
bmcAoLPDS7CjTkm35ec6m+nwAaGHZC/j
=Dnua
-----END PGP SIGNATURE-----

Re: Changing unlabeled_t on files to invalid_label_t.

[Stephen Smalley]

On 01/10/2014 11:13 AM, Daniel J Walsh wrote:
> On 01/10/2014 11:06 AM, Stephen Smalley wrote:
>> On 01/09/2014 04:53 PM, Daniel J Walsh wrote:
>>> We would like to change
>>>
>>> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
>>>
>>> to something like
>>>
>>> sid file_labels
>>> gen_context(system_u:object_r:invalid_label_t,s0)
>>>
>>> Since explaining to someone that a file without a label is file_t, but if
>>> it has a label that the kernel does not understand it is labeled as
>>> unlabeled_t. A file with a label is unlabeled_t????  While a file without
>>> a label is file_t.
>>>
>>>
>>> # # unlabeled_t is the type of unlabeled objects. # Objects that have no
>>> known labeling information or that # have labels that are no longer valid
>>> are treated as having this type. #
>>>
>>> # # file_t is the default type of a file that has not yet been # assigned
>>> an extended attribute (EA) value (when using a filesystem # that supports
>>> EAs). #
>>>
>>> These two type definitions seem to conflict, with file_t winning at least
>>> on systems that support XAttrs.
> 
>> BTW, if you want to just solve the problem you originally described, you 
>> can do that just by changing policy to assign unlabeled_t to the file 
>> initial SID, and then you'll get unlabeled_t for both.  That's what we do
>> in the Android policy.
> 
> 
> Yes I am thinking about that but then we still have the unlabeled_t when the
> object is actually labeled.

Being labeled with a label unknown to the policy is effectively
equivalent to being unlabeled.

> 
> Changing file_t to unlabeled_t, then we have to change some interfaces that
> deal with file_t to deal with unlabeled_t.
> 
> and add an alias for file_t.

Re: Changing unlabeled_t on files to invalid_label_t.

[Christopher J. PeBenito]

On 01/10/14 11:06, Stephen Smalley wrote:
> On 01/09/2014 04:53 PM, Daniel J Walsh wrote:
>> We would like to change
>>
>> sid file_labels         gen_context(system_u:object_r:unlabeled_t,s0)
>>
>> to something like
>>
>> sid file_labels         gen_context(system_u:object_r:invalid_label_t,s0)
>>
>> Since explaining to someone that a file without a label is file_t, but if it
>> has a label that the kernel does not understand it is labeled as unlabeled_t.
>> A file with a label is unlabeled_t????  While a file without a label is file_t.
>>
>>
>> #
>> # unlabeled_t is the type of unlabeled objects.
>> # Objects that have no known labeling information or that
>> # have labels that are no longer valid are treated as having this type.
>> #
>>
>> #
>> # file_t is the default type of a file that has not yet been
>> # assigned an extended attribute (EA) value (when using a filesystem
>> # that supports EAs).
>> #
>>
>> These two type definitions seem to conflict, with file_t winning at least on
>> systems that support XAttrs.
> 
> BTW, if you want to just solve the problem you originally described, you
> can do that just by changing policy to assign unlabeled_t to the file
> initial SID, and then you'll get unlabeled_t for both.  That's what we
> do in the Android policy.

I'm not opposed to doing this in refpolicy.  The concept of what file_t means is tough to explain w/o talking about the mechanics.  It shouldn't be a major change, since normally no one should be doing anything with file_t files other than to fix their label (i.e. same thing as for unlabeled_t files).

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com