No default labels, is it intentional?

[Göran Uddeborg]

I'm running a "restorecon -n -R -v /" from cron once a month, just to
be careful and know what is happening.  Last night when it ran, I got
a lot of error messages like these:

restorecon:  Warning no default label for /dev/pts/3

and

restorecon:  Warning no default label for /tmp/efs0YYVa79.html

There were a couple for things in /dev, and lots of them for things in
/tmp.

I have lately been upgrading bit by bit to Fedora 18 (the beta,
strictly speaking, since the final release isn't officially out at the
time of this writing), so I assume the new message is related to these
upgrades.  But why?  When I list file contexts, I see rules like this:

/dev/pts(/.*)?                                     all files         
<<None>>

So I guess it is not a simple mistake.  But what is the reason?  Why
don't some /dev entries, and almost the entire /tmp directory, have
any default context any more?

[Dominick Grift]

On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
>  I'm running a "restorecon -n -R -v /" from cron once a
> month, just to
>  be careful and know what is happening.  Last night when it ran, I got
>  a lot of error messages like these:
>  
>  restorecon:  Warning no default label for /dev/pts/3
>  
>  and
>  
>  restorecon:  Warning no default label for /tmp/efs0YYVa79.html
>  
>  There were a couple for things in /dev, and lots of them for things in
>  /tmp.
>  
>  I have lately been upgrading bit by bit to Fedora 18 (the beta,
>  strictly speaking, since the final release isn't officially out at the
>  time of this writing), so I assume the new message is related to these
>  upgrades.  But why?  When I list file contexts, I see rules like this:
>  
>  /dev/pts(/.*)?                                     all files         
> <<None>>
>  
>  So I guess it is not a simple mistake.  But what is the reason?  Why
>  don't some /dev entries, and almost the entire /tmp directory, have
>  any default context any more? 
It has to do with some optional security models like mcs, mls and ubac
and the nature of their security attributes i believe 

For example if you create a file in /tmp with a compartment of s0:c23
then you do not want a relabel to reset it because that would declassify
the file back to s0

SELinux cannot determine that the file should be labeled s0:c23 because
a unprivileged user with access to the compartment decided that

So by ignoring the context altogether you can be sure that the file will
not get declassified by restorecon/fixfiles

So you will see this in public places like /tmp etc.

There is a similar issue with types. Users may have some discretion over
select types to relabel to and from. SELinux cannot determine that a
user decided to label from example file ~/bla type httpd_user_content_t.

So with types there is a different approach: some types are declared
customizable types. If a file has a customizable type then SELinux will
not try to relabel it (so that it wont get unintentionally declassified)
unless you use the -F flag.

The identity field by default does not get reset unless one uses
restorecon with the -F flag

With MLS security models processes are forced to operate on specified
security levels for the sake of enforcing confidentiality. Files that
may be affected and are in public places are not flagged to be reset
with the <<None>>

Disclaimer: this is my understanding of the issue but i might be wrong



>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel J Walsh]

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

On 01/15/2013 09:15 AM, Dominick Grift wrote:
>  On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
> > I'm running a "restorecon -n -R -v /" from cron once a month, just to
> be
> > careful and know what is happening.  Last night when it ran, I got a lot
> > of error messages like these:
> > 
> > restorecon:  Warning no default label for /dev/pts/3
> > 
> > and
> > 
> > restorecon:  Warning no default label for /tmp/efs0YYVa79.html
> > 
> > There were a couple for things in /dev, and lots of them for things in 
> > /tmp.
> > 
> > I have lately been upgrading bit by bit to Fedora 18 (the beta, strictly
> > speaking, since the final release isn't officially out at the time of
> > this writing), so I assume the new message is related to these upgrades.
> > But why?  When I list file contexts, I see rules like this:
> > 
> > /dev/pts(/.*)?                                     all files
> > <<None>>
> > 
> > So I guess it is not a simple mistake.  But what is the reason?  Why 
> > don't some /dev entries, and almost the entire /tmp directory, have any
> > default context any more?
>  
>  It has to do with some optional security models like mcs, mls and ubac and
>  the nature of their security attributes i believe
>  
>  For example if you create a file in /tmp with a compartment of s0:c23 then
>  you do not want a relabel to reset it because that would declassify the
>  file back to s0
>  
>  SELinux cannot determine that the file should be labeled s0:c23 because a
>  unprivileged user with access to the compartment decided that
>  
>  So by ignoring the context altogether you can be sure that the file will 
>  not get declassified by restorecon/fixfiles
>  
>  So you will see this in public places like /tmp etc.
>  
>  There is a similar issue with types. Users may have some discretion over 
>  select types to relabel to and from. SELinux cannot determine that a user
>  decided to label from example file ~/bla type httpd_user_content_t.
>  
>  So with types there is a different approach: some types are declared 
>  customizable types. If a file has a customizable type then SELinux will not
>  try to relabel it (so that it wont get unintentionally declassified) unless
>  you use the -F flag.
>  
>  The identity field by default does not get reset unless one uses restorecon
>  with the -F flag
>  
>  With MLS security models processes are forced to operate on specified 
>  security levels for the sake of enforcing confidentiality. Files that may
>  be affected and are in public places are not flagged to be reset with the
>  <<None>>
>  
>  Disclaimer: this is my understanding of the issue but i might be wrong
>  
>  
>  
> > -- selinux mailing list selinux(a)lists.fedoraproject.org 
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
Yes the basic idea is in certain directories like mnt_t, tmp_t, tmpfs_t we do
not have a standard definition of content in these directories.  So <<none>>
says any content could be here, so don't change the labels.  For example a
user does cp -a ~/.ssh /tmp  Would move ssh_home_t content to /tmp, if you ran
restorecon on it and we had default label of tmp_t or user_tmp_t, then all
apps could read tmp_t could not read the content.

Modern restorecon in RHEL7 and Latest Fedoras does not change any components
of the security context other then the type field.  unless you specify force.
 This is something we want avoid as we move forward with MCS labeling and MLS
Labeling.  If you use containers or static labeling for virtual machines, you
do not want restorecon changing the MLS/MCS field.

The reason you are noticing this is we added an error check to restorecon to
tell the user that restorecon /mnt/foobar did not do anything.

restorecon -R /mnt

Will not output the error, since we wanted to quiet the noise, but if you get
verbose, you will get the noise.  I guess we could add a -vv for realy
verbose, if the message is aggravating.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlD1boQACgkQrlYvE4MpobPQsQCg28H3aTvnu5SQMqxkBEwplheZ
> 0WwAnRZcEjR8vutPvgzDkiOmUFUtZOWf
> =FwWS
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
>  On 01/15/2013 09:15 AM, Dominick Grift wrote:
>  > On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
>  >> I'm running a "restorecon -n -R -v /" from cron once a month, just
> to be
>  >> careful and know what is happening.  Last night when it ran, I got a lot
>  >> of error messages like these:
>  >> 
>  >> restorecon:  Warning no default label for /dev/pts/3
>  >> 
>  >> and
>  >> 
>  >> restorecon:  Warning no default label for /tmp/efs0YYVa79.html
>  >> 
>  >> There were a couple for things in /dev, and lots of them for things in 
>  >> /tmp.
>  >> 
>  >> I have lately been upgrading bit by bit to Fedora 18 (the beta, strictly
>  >> speaking, since the final release isn't officially out at the time of
>  >> this writing), so I assume the new message is related to these upgrades.
>  >> But why?  When I list file contexts, I see rules like this:
>  >> 
>  >> /dev/pts(/.*)?                                     all files
>  >> <<None>>
>  >> 
>  >> So I guess it is not a simple mistake.  But what is the reason?  Why 
>  >> don't some /dev entries, and almost the entire /tmp directory, have any
>  >> default context any more?
>  > 
>  > It has to do with some optional security models like mcs, mls and ubac and
>  > the nature of their security attributes i believe
>  > 
>  > For example if you create a file in /tmp with a compartment of s0:c23 then
>  > you do not want a relabel to reset it because that would declassify the
>  > file back to s0
>  > 
>  > SELinux cannot determine that the file should be labeled s0:c23 because a
>  > unprivileged user with access to the compartment decided that
>  > 
>  > So by ignoring the context altogether you can be sure that the file will 
>  > not get declassified by restorecon/fixfiles
>  > 
>  > So you will see this in public places like /tmp etc.
>  > 
>  > There is a similar issue with types. Users may have some discretion over 
>  > select types to relabel to and from. SELinux cannot determine that a user
>  > decided to label from example file ~/bla type httpd_user_content_t.
>  > 
>  > So with types there is a different approach: some types are declared 
>  > customizable types. If a file has a customizable type then SELinux will not
>  > try to relabel it (so that it wont get unintentionally declassified) unless
>  > you use the -F flag.
>  > 
>  > The identity field by default does not get reset unless one uses restorecon
>  > with the -F flag
>  > 
>  > With MLS security models processes are forced to operate on specified 
>  > security levels for the sake of enforcing confidentiality. Files that may
>  > be affected and are in public places are not flagged to be reset with the
>  > <<None>>
>  > 
>  > Disclaimer: this is my understanding of the issue but i might be wrong
>  > 
>  > 
>  > 
>  >> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  >> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > 
>  > 
>  > -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > 
>  Yes the basic idea is in certain directories like mnt_t, tmp_t, tmpfs_t we do
>  not have a standard definition of content in these directories.  So <<none>>
>  says any content could be here, so don't change the labels.  For example a
>  user does cp -a ~/.ssh /tmp  Would move ssh_home_t content to /tmp, if you ran
>  restorecon on it and we had default label of tmp_t or user_tmp_t, then all
>  apps could read tmp_t could not read the content.
>  
>  Modern restorecon in RHEL7 and Latest Fedoras does not change any components
>  of the security context other then the type field.  unless you specify force.
>   This is something we want avoid as we move forward with MCS labeling and MLS
>  Labeling.  If you use containers or static labeling for virtual machines, you
>  do not want restorecon changing the MLS/MCS field.
>  
>  The reason you are noticing this is we added an error check to restorecon to
>  tell the user that restorecon /mnt/foobar did not do anything.
>  
>  restorecon -R /mnt
>  
>  Will not output the error, since we wanted to quiet the noise, but if you get
>  verbose, you will get the noise.  I guess we could add a -vv for realy
>  verbose, if the message is aggravating. 
By the way, we probably want to not relabel content
in /var/lib/libvirt/filesystems.

I did a relabel and all my container contexts were reset

[Daniel J Walsh]

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

On 01/15/2013 10:03 AM, Dominick Grift wrote:
>  On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
> > On 01/15/2013 09:15 AM, Dominick Grift wrote:
> >> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
> >>> I'm running a "restorecon -n -R -v /" from cron once a month,
> just to
> >>> be careful and know what is happening.  Last night when it ran, I got
> >>> a lot of error messages like these:
> >>> 
> >>> restorecon:  Warning no default label for /dev/pts/3
> >>> 
> >>> and
> >>> 
> >>> restorecon:  Warning no default label for /tmp/efs0YYVa79.html
> >>> 
> >>> There were a couple for things in /dev, and lots of them for things
> >>> in /tmp.
> >>> 
> >>> I have lately been upgrading bit by bit to Fedora 18 (the beta,
> >>> strictly speaking, since the final release isn't officially out at
> >>> the time of this writing), so I assume the new message is related to
> >>> these upgrades. But why?  When I list file contexts, I see rules like
> >>> this:
> >>> 
> >>> /dev/pts(/.*)?                                     all files 
> >>> <<None>>
> >>> 
> >>> So I guess it is not a simple mistake.  But what is the reason?  Why
> >>>  don't some /dev entries, and almost the entire /tmp directory, have
> >>> any default context any more?
> >> 
> >> It has to do with some optional security models like mcs, mls and ubac
> >> and the nature of their security attributes i believe
> >> 
> >> For example if you create a file in /tmp with a compartment of s0:c23
> >> then you do not want a relabel to reset it because that would
> >> declassify the file back to s0
> >> 
> >> SELinux cannot determine that the file should be labeled s0:c23 because
> >> a unprivileged user with access to the compartment decided that
> >> 
> >> So by ignoring the context altogether you can be sure that the file
> >> will not get declassified by restorecon/fixfiles
> >> 
> >> So you will see this in public places like /tmp etc.
> >> 
> >> There is a similar issue with types. Users may have some discretion
> >> over select types to relabel to and from. SELinux cannot determine that
> >> a user decided to label from example file ~/bla type
> >> httpd_user_content_t.
> >> 
> >> So with types there is a different approach: some types are declared 
> >> customizable types. If a file has a customizable type then SELinux will
> >> not try to relabel it (so that it wont get unintentionally
> >> declassified) unless you use the -F flag.
> >> 
> >> The identity field by default does not get reset unless one uses
> >> restorecon with the -F flag
> >> 
> >> With MLS security models processes are forced to operate on specified 
> >> security levels for the sake of enforcing confidentiality. Files that
> >> may be affected and are in public places are not flagged to be reset
> >> with the <<None>>
> >> 
> >> Disclaimer: this is my understanding of the issue but i might be wrong
> >> 
> >> 
> >> 
> >>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >> 
> >> 
> >> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >> 
> > Yes the basic idea is in certain directories like mnt_t, tmp_t, tmpfs_t
> > we do not have a standard definition of content in these directories.  So
> > <<none>> says any content could be here, so don't change the labels. 
> For
> > example a user does cp -a ~/.ssh /tmp  Would move ssh_home_t content to
> > /tmp, if you ran restorecon on it and we had default label of tmp_t or
> > user_tmp_t, then all apps could read tmp_t could not read the content.
> > 
> > Modern restorecon in RHEL7 and Latest Fedoras does not change any
> > components of the security context other then the type field.  unless you
> > specify force. This is something we want avoid as we move forward with
> > MCS labeling and MLS Labeling.  If you use containers or static labeling
> > for virtual machines, you do not want restorecon changing the MLS/MCS
> > field.
> > 
> > The reason you are noticing this is we added an error check to restorecon
> > to tell the user that restorecon /mnt/foobar did not do anything.
> > 
> > restorecon -R /mnt
> > 
> > Will not output the error, since we wanted to quiet the noise, but if you
> > get verbose, you will get the noise.  I guess we could add a -vv for
> > realy verbose, if the message is aggravating.
>  
>  By the way, we probably want to not relabel content in
>  /var/lib/libvirt/filesystems.
>  
>  I did a relabel and all my container contexts were reset
>   
Really, I don't see that

# restorecon -R -v /var/lib/libvirt/filesystems/
# ls -lZ /var/lib/libvirt/filesystems/
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 myapache
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlD1cXUACgkQrlYvE4MpobO39gCfQ8TFEV9WJ+RXw8K+iAhVYvVM
> 2WEAnisF73lXQzpdWYG/D00JJoXSCHT4
> =5Pqg
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
>  On 01/15/2013 10:03 AM, Dominick Grift wrote:
>  > On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
>  >> On 01/15/2013 09:15 AM, Dominick Grift wrote:
>  >>> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
>  >>>> I'm running a "restorecon -n -R -v /" from cron once a
> month, just to
>  >>>> be careful and know what is happening.  Last night when it ran, I got
>  >>>> a lot of error messages like these:
>  >>>> 
>  >>>> restorecon:  Warning no default label for /dev/pts/3
>  >>>> 
>  >>>> and
>  >>>> 
>  >>>> restorecon:  Warning no default label for /tmp/efs0YYVa79.html
>  >>>> 
>  >>>> There were a couple for things in /dev, and lots of them for things
>  >>>> in /tmp.
>  >>>> 
>  >>>> I have lately been upgrading bit by bit to Fedora 18 (the beta,
>  >>>> strictly speaking, since the final release isn't officially out at
>  >>>> the time of this writing), so I assume the new message is related to
>  >>>> these upgrades. But why?  When I list file contexts, I see rules like
>  >>>> this:
>  >>>> 
>  >>>> /dev/pts(/.*)?                                     all files 
>  >>>> <<None>>
>  >>>> 
>  >>>> So I guess it is not a simple mistake.  But what is the reason?  Why
>  >>>>  don't some /dev entries, and almost the entire /tmp directory,
> have
>  >>>> any default context any more?
>  >>> 
>  >>> It has to do with some optional security models like mcs, mls and ubac
>  >>> and the nature of their security attributes i believe
>  >>> 
>  >>> For example if you create a file in /tmp with a compartment of s0:c23
>  >>> then you do not want a relabel to reset it because that would
>  >>> declassify the file back to s0
>  >>> 
>  >>> SELinux cannot determine that the file should be labeled s0:c23 because
>  >>> a unprivileged user with access to the compartment decided that
>  >>> 
>  >>> So by ignoring the context altogether you can be sure that the file
>  >>> will not get declassified by restorecon/fixfiles
>  >>> 
>  >>> So you will see this in public places like /tmp etc.
>  >>> 
>  >>> There is a similar issue with types. Users may have some discretion
>  >>> over select types to relabel to and from. SELinux cannot determine that
>  >>> a user decided to label from example file ~/bla type
>  >>> httpd_user_content_t.
>  >>> 
>  >>> So with types there is a different approach: some types are declared 
>  >>> customizable types. If a file has a customizable type then SELinux will
>  >>> not try to relabel it (so that it wont get unintentionally
>  >>> declassified) unless you use the -F flag.
>  >>> 
>  >>> The identity field by default does not get reset unless one uses
>  >>> restorecon with the -F flag
>  >>> 
>  >>> With MLS security models processes are forced to operate on specified 
>  >>> security levels for the sake of enforcing confidentiality. Files that
>  >>> may be affected and are in public places are not flagged to be reset
>  >>> with the <<None>>
>  >>> 
>  >>> Disclaimer: this is my understanding of the issue but i might be wrong
>  >>> 
>  >>> 
>  >>> 
>  >>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>> 
>  >>> 
>  >>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  >>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>> 
>  >> Yes the basic idea is in certain directories like mnt_t, tmp_t, tmpfs_t
>  >> we do not have a standard definition of content in these directories.  So
>  >> <<none>> says any content could be here, so don't change the
> labels.  For
>  >> example a user does cp -a ~/.ssh /tmp  Would move ssh_home_t content to
>  >> /tmp, if you ran restorecon on it and we had default label of tmp_t or
>  >> user_tmp_t, then all apps could read tmp_t could not read the content.
>  >> 
>  >> Modern restorecon in RHEL7 and Latest Fedoras does not change any
>  >> components of the security context other then the type field.  unless you
>  >> specify force. This is something we want avoid as we move forward with
>  >> MCS labeling and MLS Labeling.  If you use containers or static labeling
>  >> for virtual machines, you do not want restorecon changing the MLS/MCS
>  >> field.
>  >> 
>  >> The reason you are noticing this is we added an error check to restorecon
>  >> to tell the user that restorecon /mnt/foobar did not do anything.
>  >> 
>  >> restorecon -R /mnt
>  >> 
>  >> Will not output the error, since we wanted to quiet the noise, but if you
>  >> get verbose, you will get the noise.  I guess we could add a -vv for
>  >> realy verbose, if the message is aggravating.
>  > 
>  > By the way, we probably want to not relabel content in
>  > /var/lib/libvirt/filesystems.
>  > 
>  > I did a relabel and all my container contexts were reset
>  > 
>  Really, I don't see that
>  
>  # restorecon -R -v /var/lib/libvirt/filesystems/
>  # ls -lZ /var/lib/libvirt/filesystems/
>  drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1
>  drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1
>  drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan
>  drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 myapache
>  drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql
>   
I did see it but i did a fixfiles onboot

[Dominick Grift]

On Tue, 2013-01-15 at 20:23 +0100, Dominick Grift wrote:
>  On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
>  > On 01/15/2013 10:03 AM, Dominick Grift wrote:
>  > > On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
>  > >> On 01/15/2013 09:15 AM, Dominick Grift wrote:
>  > >>> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
>  > >>>> I'm running a "restorecon -n -R -v /" from cron once
> a month, just to
>  > >>>> be careful and know what is happening.  Last night when it ran, I
> got
>  > >>>> a lot of error messages like these:
>  > >>>> 
>  > >>>> restorecon:  Warning no default label for /dev/pts/3
>  > >>>> 
>  > >>>> and
>  > >>>> 
>  > >>>> restorecon:  Warning no default label for /tmp/efs0YYVa79.html
>  > >>>> 
>  > >>>> There were a couple for things in /dev, and lots of them for
> things
>  > >>>> in /tmp.
>  > >>>> 
>  > >>>> I have lately been upgrading bit by bit to Fedora 18 (the beta,
>  > >>>> strictly speaking, since the final release isn't officially out
> at
>  > >>>> the time of this writing), so I assume the new message is related
> to
>  > >>>> these upgrades. But why?  When I list file contexts, I see rules
> like
>  > >>>> this:
>  > >>>> 
>  > >>>> /dev/pts(/.*)?                                     all files 
>  > >>>> <<None>>
>  > >>>> 
>  > >>>> So I guess it is not a simple mistake.  But what is the reason? 
> Why
>  > >>>>  don't some /dev entries, and almost the entire /tmp directory,
> have
>  > >>>> any default context any more?
>  > >>> 
>  > >>> It has to do with some optional security models like mcs, mls and ubac
>  > >>> and the nature of their security attributes i believe
>  > >>> 
>  > >>> For example if you create a file in /tmp with a compartment of s0:c23
>  > >>> then you do not want a relabel to reset it because that would
>  > >>> declassify the file back to s0
>  > >>> 
>  > >>> SELinux cannot determine that the file should be labeled s0:c23
> because
>  > >>> a unprivileged user with access to the compartment decided that
>  > >>> 
>  > >>> So by ignoring the context altogether you can be sure that the file
>  > >>> will not get declassified by restorecon/fixfiles
>  > >>> 
>  > >>> So you will see this in public places like /tmp etc.
>  > >>> 
>  > >>> There is a similar issue with types. Users may have some discretion
>  > >>> over select types to relabel to and from. SELinux cannot determine
> that
>  > >>> a user decided to label from example file ~/bla type
>  > >>> httpd_user_content_t.
>  > >>> 
>  > >>> So with types there is a different approach: some types are declared 
>  > >>> customizable types. If a file has a customizable type then SELinux
> will
>  > >>> not try to relabel it (so that it wont get unintentionally
>  > >>> declassified) unless you use the -F flag.
>  > >>> 
>  > >>> The identity field by default does not get reset unless one uses
>  > >>> restorecon with the -F flag
>  > >>> 
>  > >>> With MLS security models processes are forced to operate on specified 
>  > >>> security levels for the sake of enforcing confidentiality. Files that
>  > >>> may be affected and are in public places are not flagged to be reset
>  > >>> with the <<None>>
>  > >>> 
>  > >>> Disclaimer: this is my understanding of the issue but i might be wrong
>  > >>> 
>  > >>> 
>  > >>> 
>  > >>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  > >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > >>> 
>  > >>> 
>  > >>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  > >>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > >>> 
>  > >> Yes the basic idea is in certain directories like mnt_t, tmp_t, tmpfs_t
>  > >> we do not have a standard definition of content in these directories.  So
>  > >> <<none>> says any content could be here, so don't change
> the labels.  For
>  > >> example a user does cp -a ~/.ssh /tmp  Would move ssh_home_t content to
>  > >> /tmp, if you ran restorecon on it and we had default label of tmp_t or
>  > >> user_tmp_t, then all apps could read tmp_t could not read the content.
>  > >> 
>  > >> Modern restorecon in RHEL7 and Latest Fedoras does not change any
>  > >> components of the security context other then the type field.  unless you
>  > >> specify force. This is something we want avoid as we move forward with
>  > >> MCS labeling and MLS Labeling.  If you use containers or static labeling
>  > >> for virtual machines, you do not want restorecon changing the MLS/MCS
>  > >> field.
>  > >> 
>  > >> The reason you are noticing this is we added an error check to restorecon
>  > >> to tell the user that restorecon /mnt/foobar did not do anything.
>  > >> 
>  > >> restorecon -R /mnt
>  > >> 
>  > >> Will not output the error, since we wanted to quiet the noise, but if you
>  > >> get verbose, you will get the noise.  I guess we could add a -vv for
>  > >> realy verbose, if the message is aggravating.
>  > > 
>  > > By the way, we probably want to not relabel content in
>  > > /var/lib/libvirt/filesystems.
>  > > 
>  > > I did a relabel and all my container contexts were reset
>  > > 
>  > Really, I don't see that
>  > 
>  > # restorecon -R -v /var/lib/libvirt/filesystems/
>  > # ls -lZ /var/lib/libvirt/filesystems/
>  > drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1
>  > drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1
>  > drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan
>  > drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 myapache
>  > drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql
>  > 
>  
>  I did see it but i did a fixfiles onboot
>   

# pwd
/var/lib/libvirt/filesystems/container1/etc/httpd/conf
[root@virt conf]# ls -alZ
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 .
drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 ..
-rw-r--r--. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2
httpd.conf
-rw-r--r--. root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 magic
[root@virt conf]# restorecon -R -v -F httpd.conf
restorecon
reset /var/lib/libvirt/filesystems/container1/etc/httpd/conf/httpd.conf
context
system_u:object_r:svirt_lxc_file_t:s0:c1,c2->system_u:object_r:virt_var_lib_t:s0

[Daniel J Walsh]

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

On 01/15/2013 02:28 PM, Dominick Grift wrote:
>  
>  On Tue, 2013-01-15 at 20:23 +0100, Dominick Grift wrote:
> > On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
> >> On 01/15/2013 10:03 AM, Dominick Grift wrote:
> >>> On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
> >>>> On 01/15/2013 09:15 AM, Dominick Grift wrote:
> >>>>> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
> >>>>>> I'm running a "restorecon -n -R -v /" from cron
> once a month,
> >>>>>> just to be careful and know what is happening.  Last night when
> >>>>>> it ran, I got a lot of error messages like these:
> >>>>>> 
> >>>>>> restorecon:  Warning no default label for /dev/pts/3
> >>>>>> 
> >>>>>> and
> >>>>>> 
> >>>>>> restorecon:  Warning no default label for /tmp/efs0YYVa79.html
> >>>>>> 
> >>>>>> There were a couple for things in /dev, and lots of them for
> >>>>>> things in /tmp.
> >>>>>> 
> >>>>>> I have lately been upgrading bit by bit to Fedora 18 (the
> >>>>>> beta, strictly speaking, since the final release isn't
> >>>>>> officially out at the time of this writing), so I assume the
> >>>>>> new message is related to these upgrades. But why?  When I list
> >>>>>> file contexts, I see rules like this:
> >>>>>> 
> >>>>>> /dev/pts(/.*)?                                     all files 
> >>>>>> <<None>>
> >>>>>> 
> >>>>>> So I guess it is not a simple mistake.  But what is the reason?
> >>>>>> Why don't some /dev entries, and almost the entire /tmp
> >>>>>> directory, have any default context any more?
> >>>>> 
> >>>>> It has to do with some optional security models like mcs, mls and
> >>>>> ubac and the nature of their security attributes i believe
> >>>>> 
> >>>>> For example if you create a file in /tmp with a compartment of
> >>>>> s0:c23 then you do not want a relabel to reset it because that
> >>>>> would declassify the file back to s0
> >>>>> 
> >>>>> SELinux cannot determine that the file should be labeled s0:c23
> >>>>> because a unprivileged user with access to the compartment
> >>>>> decided that
> >>>>> 
> >>>>> So by ignoring the context altogether you can be sure that the
> >>>>> file will not get declassified by restorecon/fixfiles
> >>>>> 
> >>>>> So you will see this in public places like /tmp etc.
> >>>>> 
> >>>>> There is a similar issue with types. Users may have some
> >>>>> discretion over select types to relabel to and from. SELinux
> >>>>> cannot determine that a user decided to label from example file
> >>>>> ~/bla type httpd_user_content_t.
> >>>>> 
> >>>>> So with types there is a different approach: some types are
> >>>>> declared customizable types. If a file has a customizable type
> >>>>> then SELinux will not try to relabel it (so that it wont get
> >>>>> unintentionally declassified) unless you use the -F flag.
> >>>>> 
> >>>>> The identity field by default does not get reset unless one uses 
> >>>>> restorecon with the -F flag
> >>>>> 
> >>>>> With MLS security models processes are forced to operate on
> >>>>> specified security levels for the sake of enforcing
> >>>>> confidentiality. Files that may be affected and are in public
> >>>>> places are not flagged to be reset with the <<None>>
> >>>>> 
> >>>>> Disclaimer: this is my understanding of the issue but i might be
> >>>>> wrong
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>>>> 
> >>>>> 
> >>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>>>> 
> >>>> Yes the basic idea is in certain directories like mnt_t, tmp_t,
> >>>> tmpfs_t we do not have a standard definition of content in these
> >>>> directories.  So <<none>> says any content could be here, so
> don't
> >>>> change the labels.  For example a user does cp -a ~/.ssh /tmp
> >>>> Would move ssh_home_t content to /tmp, if you ran restorecon on it
> >>>> and we had default label of tmp_t or user_tmp_t, then all apps
> >>>> could read tmp_t could not read the content.
> >>>> 
> >>>> Modern restorecon in RHEL7 and Latest Fedoras does not change any 
> >>>> components of the security context other then the type field.
> >>>> unless you specify force. This is something we want avoid as we
> >>>> move forward with MCS labeling and MLS Labeling.  If you use
> >>>> containers or static labeling for virtual machines, you do not want
> >>>> restorecon changing the MLS/MCS field.
> >>>> 
> >>>> The reason you are noticing this is we added an error check to
> >>>> restorecon to tell the user that restorecon /mnt/foobar did not do
> >>>> anything.
> >>>> 
> >>>> restorecon -R /mnt
> >>>> 
> >>>> Will not output the error, since we wanted to quiet the noise, but
> >>>> if you get verbose, you will get the noise.  I guess we could add a
> >>>> -vv for realy verbose, if the message is aggravating.
> >>> 
> >>> By the way, we probably want to not relabel content in 
> >>> /var/lib/libvirt/filesystems.
> >>> 
> >>> I did a relabel and all my container contexts were reset
> >>> 
> >> Really, I don't see that
> >> 
> >> # restorecon -R -v /var/lib/libvirt/filesystems/ # ls -lZ
> >> /var/lib/libvirt/filesystems/ drwxr-xr-x. root root
> >> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1 drwxr-xr-x. root
> >> root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1 drwxr-xr-x.
> >> root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan 
> >> drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023
> >> myapache drwxr-xr-x. root root
> >> system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql
> >> 
> > 
> > I did see it but i did a fixfiles onboot
> > 
>  
>  
>  # pwd /var/lib/libvirt/filesystems/container1/etc/httpd/conf [root@virt
>  conf]# ls -alZ drwxr-xr-x. root root
>  system_u:object_r:svirt_lxc_file_t:s0:c1,c2 . drwxr-xr-x. root root
>  system_u:object_r:svirt_lxc_file_t:s0:c1,c2 .. -rw-r--r--. root root
>  system_u:object_r:svirt_lxc_file_t:s0:c1,c2 httpd.conf -rw-r--r--. root
>  root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 magic [root@virt conf]#
>  restorecon -R -v -F httpd.conf restorecon reset
>  /var/lib/libvirt/filesystems/container1/etc/httpd/conf/httpd.conf context 
>  system_u:object_r:svirt_lxc_file_t:s0:c1,c2->system_u:object_r:virt_var_lib_t:s0
>
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
Right , is fixfiles onboot doing a force?  If it is, that is a  bug.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlD1weoACgkQrlYvE4MpobMexgCdEH+1T6U39+mX5/yjKPpV4cYB
> lagAn22JhANvswewyeXme1fF192MqG8F
> =OwBe
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Tue, 2013-01-15 at 15:54 -0500, Daniel J Walsh wrote:
>  On 01/15/2013 02:28 PM, Dominick Grift wrote:
>  > 
>  > On Tue, 2013-01-15 at 20:23 +0100, Dominick Grift wrote:
>  >> On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
>  >>> On 01/15/2013 10:03 AM, Dominick Grift wrote:
>  >>>> On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
>  >>>>> On 01/15/2013 09:15 AM, Dominick Grift wrote:
>  >>>>>> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
>  >>>>>>> I'm running a "restorecon -n -R -v /" from
> cron once a month,
>  >>>>>>> just to be careful and know what is happening.  Last night
> when
>  >>>>>>> it ran, I got a lot of error messages like these:
>  >>>>>>> 
>  >>>>>>> restorecon:  Warning no default label for /dev/pts/3
>  >>>>>>> 
>  >>>>>>> and
>  >>>>>>> 
>  >>>>>>> restorecon:  Warning no default label for
> /tmp/efs0YYVa79.html
>  >>>>>>> 
>  >>>>>>> There were a couple for things in /dev, and lots of them
> for
>  >>>>>>> things in /tmp.
>  >>>>>>> 
>  >>>>>>> I have lately been upgrading bit by bit to Fedora 18 (the
>  >>>>>>> beta, strictly speaking, since the final release isn't
>  >>>>>>> officially out at the time of this writing), so I assume
> the
>  >>>>>>> new message is related to these upgrades. But why?  When I
> list
>  >>>>>>> file contexts, I see rules like this:
>  >>>>>>> 
>  >>>>>>> /dev/pts(/.*)?                                     all files
>
>  >>>>>>> <<None>>
>  >>>>>>> 
>  >>>>>>> So I guess it is not a simple mistake.  But what is the
> reason?
>  >>>>>>> Why don't some /dev entries, and almost the entire /tmp
>  >>>>>>> directory, have any default context any more?
>  >>>>>> 
>  >>>>>> It has to do with some optional security models like mcs, mls
> and
>  >>>>>> ubac and the nature of their security attributes i believe
>  >>>>>> 
>  >>>>>> For example if you create a file in /tmp with a compartment of
>  >>>>>> s0:c23 then you do not want a relabel to reset it because that
>  >>>>>> would declassify the file back to s0
>  >>>>>> 
>  >>>>>> SELinux cannot determine that the file should be labeled s0:c23
>  >>>>>> because a unprivileged user with access to the compartment
>  >>>>>> decided that
>  >>>>>> 
>  >>>>>> So by ignoring the context altogether you can be sure that the
>  >>>>>> file will not get declassified by restorecon/fixfiles
>  >>>>>> 
>  >>>>>> So you will see this in public places like /tmp etc.
>  >>>>>> 
>  >>>>>> There is a similar issue with types. Users may have some
>  >>>>>> discretion over select types to relabel to and from. SELinux
>  >>>>>> cannot determine that a user decided to label from example file
>  >>>>>> ~/bla type httpd_user_content_t.
>  >>>>>> 
>  >>>>>> So with types there is a different approach: some types are
>  >>>>>> declared customizable types. If a file has a customizable type
>  >>>>>> then SELinux will not try to relabel it (so that it wont get
>  >>>>>> unintentionally declassified) unless you use the -F flag.
>  >>>>>> 
>  >>>>>> The identity field by default does not get reset unless one uses
>
>  >>>>>> restorecon with the -F flag
>  >>>>>> 
>  >>>>>> With MLS security models processes are forced to operate on
>  >>>>>> specified security levels for the sake of enforcing
>  >>>>>> confidentiality. Files that may be affected and are in public
>  >>>>>> places are not flagged to be reset with the
> <<None>>
>  >>>>>> 
>  >>>>>> Disclaimer: this is my understanding of the issue but i might
> be
>  >>>>>> wrong
>  >>>>>> 
>  >>>>>> 
>  >>>>>> 
>  >>>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>>>>> 
>  >>>>>> 
>  >>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  >>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>>>>> 
>  >>>>> Yes the basic idea is in certain directories like mnt_t, tmp_t,
>  >>>>> tmpfs_t we do not have a standard definition of content in these
>  >>>>> directories.  So <<none>> says any content could be
> here, so don't
>  >>>>> change the labels.  For example a user does cp -a ~/.ssh /tmp
>  >>>>> Would move ssh_home_t content to /tmp, if you ran restorecon on it
>  >>>>> and we had default label of tmp_t or user_tmp_t, then all apps
>  >>>>> could read tmp_t could not read the content.
>  >>>>> 
>  >>>>> Modern restorecon in RHEL7 and Latest Fedoras does not change any 
>  >>>>> components of the security context other then the type field.
>  >>>>> unless you specify force. This is something we want avoid as we
>  >>>>> move forward with MCS labeling and MLS Labeling.  If you use
>  >>>>> containers or static labeling for virtual machines, you do not want
>  >>>>> restorecon changing the MLS/MCS field.
>  >>>>> 
>  >>>>> The reason you are noticing this is we added an error check to
>  >>>>> restorecon to tell the user that restorecon /mnt/foobar did not do
>  >>>>> anything.
>  >>>>> 
>  >>>>> restorecon -R /mnt
>  >>>>> 
>  >>>>> Will not output the error, since we wanted to quiet the noise, but
>  >>>>> if you get verbose, you will get the noise.  I guess we could add a
>  >>>>> -vv for realy verbose, if the message is aggravating.
>  >>>> 
>  >>>> By the way, we probably want to not relabel content in 
>  >>>> /var/lib/libvirt/filesystems.
>  >>>> 
>  >>>> I did a relabel and all my container contexts were reset
>  >>>> 
>  >>> Really, I don't see that
>  >>> 
>  >>> # restorecon -R -v /var/lib/libvirt/filesystems/ # ls -lZ
>  >>> /var/lib/libvirt/filesystems/ drwxr-xr-x. root root
>  >>> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1 drwxr-xr-x. root
>  >>> root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1 drwxr-xr-x.
>  >>> root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan 
>  >>> drwxr-xr-x. root root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023
>  >>> myapache drwxr-xr-x. root root
>  >>> system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql
>  >>> 
>  >> 
>  >> I did see it but i did a fixfiles onboot
>  >> 
>  > 
>  > 
>  > # pwd /var/lib/libvirt/filesystems/container1/etc/httpd/conf [root@virt
>  > conf]# ls -alZ drwxr-xr-x. root root
>  > system_u:object_r:svirt_lxc_file_t:s0:c1,c2 . drwxr-xr-x. root root
>  > system_u:object_r:svirt_lxc_file_t:s0:c1,c2 .. -rw-r--r--. root root
>  > system_u:object_r:svirt_lxc_file_t:s0:c1,c2 httpd.conf -rw-r--r--. root
>  > root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 magic [root@virt conf]#
>  > restorecon -R -v -F httpd.conf restorecon reset
>  > /var/lib/libvirt/filesystems/container1/etc/httpd/conf/httpd.conf context 
>  > system_u:object_r:svirt_lxc_file_t:s0:c1,c2->system_u:object_r:virt_var_lib_t:s0
>  >
>  > 
>  > 
>  > -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > 
>  Right , is fixfiles onboot doing a force?  If it is, that is a  bug. 
I guess it is. I had to try fixfiles onboot because quotacheck kept
creating aquota.user with the wrong type and i was denied access to
restore it ( turned out fixfiles onboot wasnt allowed it either ) we
probably want to make sure that quotacheck run by unconfined_t creates
quota db files with the proper context

[Daniel J Walsh]

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

On 01/15/2013 04:22 PM, Dominick Grift wrote:
>  On Tue, 2013-01-15 at 15:54 -0500, Daniel J Walsh wrote:
> > On 01/15/2013 02:28 PM, Dominick Grift wrote:
> >> 
> >> On Tue, 2013-01-15 at 20:23 +0100, Dominick Grift wrote:
> >>> On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
> >>>> On 01/15/2013 10:03 AM, Dominick Grift wrote:
> >>>>> On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
> >>>>>> On 01/15/2013 09:15 AM, Dominick Grift wrote:
> >>>>>>> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg wrote:
> >>>>>>>> I'm running a "restorecon -n -R -v /" from
> cron once a
> >>>>>>>> month, just to be careful and know what is happening. 
> Last
> >>>>>>>> night when it ran, I got a lot of error messages like
> >>>>>>>> these:
> >>>>>>>> 
> >>>>>>>> restorecon:  Warning no default label for /dev/pts/3
> >>>>>>>> 
> >>>>>>>> and
> >>>>>>>> 
> >>>>>>>> restorecon:  Warning no default label for
> >>>>>>>> /tmp/efs0YYVa79.html
> >>>>>>>> 
> >>>>>>>> There were a couple for things in /dev, and lots of them
> >>>>>>>> for things in /tmp.
> >>>>>>>> 
> >>>>>>>> I have lately been upgrading bit by bit to Fedora 18 (the
>
> >>>>>>>> beta, strictly speaking, since the final release
> isn't 
> >>>>>>>> officially out at the time of this writing), so I assume
> >>>>>>>> the new message is related to these upgrades. But why?
> >>>>>>>> When I list file contexts, I see rules like this:
> >>>>>>>> 
> >>>>>>>> /dev/pts(/.*)?                                     all
> >>>>>>>> files <<None>>
> >>>>>>>> 
> >>>>>>>> So I guess it is not a simple mistake.  But what is the
> >>>>>>>> reason? Why don't some /dev entries, and almost the
> entire
> >>>>>>>> /tmp directory, have any default context any more?
> >>>>>>> 
> >>>>>>> It has to do with some optional security models like mcs,
> mls
> >>>>>>> and ubac and the nature of their security attributes i
> >>>>>>> believe
> >>>>>>> 
> >>>>>>> For example if you create a file in /tmp with a compartment
> >>>>>>> of s0:c23 then you do not want a relabel to reset it because
> >>>>>>> that would declassify the file back to s0
> >>>>>>> 
> >>>>>>> SELinux cannot determine that the file should be labeled
> >>>>>>> s0:c23 because a unprivileged user with access to the
> >>>>>>> compartment decided that
> >>>>>>> 
> >>>>>>> So by ignoring the context altogether you can be sure that
> >>>>>>> the file will not get declassified by restorecon/fixfiles
> >>>>>>> 
> >>>>>>> So you will see this in public places like /tmp etc.
> >>>>>>> 
> >>>>>>> There is a similar issue with types. Users may have some 
> >>>>>>> discretion over select types to relabel to and from. SELinux
>
> >>>>>>> cannot determine that a user decided to label from example
> >>>>>>> file ~/bla type httpd_user_content_t.
> >>>>>>> 
> >>>>>>> So with types there is a different approach: some types are 
> >>>>>>> declared customizable types. If a file has a customizable
> >>>>>>> type then SELinux will not try to relabel it (so that it
> wont
> >>>>>>> get unintentionally declassified) unless you use the -F
> >>>>>>> flag.
> >>>>>>> 
> >>>>>>> The identity field by default does not get reset unless one
> >>>>>>> uses restorecon with the -F flag
> >>>>>>> 
> >>>>>>> With MLS security models processes are forced to operate on 
> >>>>>>> specified security levels for the sake of enforcing 
> >>>>>>> confidentiality. Files that may be affected and are in
> >>>>>>> public places are not flagged to be reset with the
> <<None>>
> >>>>>>> 
> >>>>>>> Disclaimer: this is my understanding of the issue but i
> might
> >>>>>>> be wrong
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>>>>>> 
> >>>>>>> 
> >>>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org 
> >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>>>>>> 
> >>>>>> Yes the basic idea is in certain directories like mnt_t,
> >>>>>> tmp_t, tmpfs_t we do not have a standard definition of content
> >>>>>> in these directories.  So <<none>> says any content
> could be
> >>>>>> here, so don't change the labels.  For example a user does
> cp
> >>>>>> -a ~/.ssh /tmp Would move ssh_home_t content to /tmp, if you
> >>>>>> ran restorecon on it and we had default label of tmp_t or
> >>>>>> user_tmp_t, then all apps could read tmp_t could not read the
> >>>>>> content.
> >>>>>> 
> >>>>>> Modern restorecon in RHEL7 and Latest Fedoras does not change
> >>>>>> any components of the security context other then the type
> >>>>>> field. unless you specify force. This is something we want
> >>>>>> avoid as we move forward with MCS labeling and MLS Labeling.
> >>>>>> If you use containers or static labeling for virtual machines,
> >>>>>> you do not want restorecon changing the MLS/MCS field.
> >>>>>> 
> >>>>>> The reason you are noticing this is we added an error check to 
> >>>>>> restorecon to tell the user that restorecon /mnt/foobar did not
> >>>>>> do anything.
> >>>>>> 
> >>>>>> restorecon -R /mnt
> >>>>>> 
> >>>>>> Will not output the error, since we wanted to quiet the noise,
> >>>>>> but if you get verbose, you will get the noise.  I guess we
> >>>>>> could add a -vv for realy verbose, if the message is
> >>>>>> aggravating.
> >>>>> 
> >>>>> By the way, we probably want to not relabel content in 
> >>>>> /var/lib/libvirt/filesystems.
> >>>>> 
> >>>>> I did a relabel and all my container contexts were reset
> >>>>> 
> >>>> Really, I don't see that
> >>>> 
> >>>> # restorecon -R -v /var/lib/libvirt/filesystems/ # ls -lZ 
> >>>> /var/lib/libvirt/filesystems/ drwxr-xr-x. root root 
> >>>> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1 drwxr-xr-x.
> >>>> root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1
> >>>> drwxr-xr-x. root root
> >>>> system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan drwxr-xr-x. root
> >>>> root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 myapache
> >>>> drwxr-xr-x. root root 
> >>>> system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql
> >>>> 
> >>> 
> >>> I did see it but i did a fixfiles onboot
> >>> 
> >> 
> >> 
> >> # pwd /var/lib/libvirt/filesystems/container1/etc/httpd/conf
> >> [root@virt conf]# ls -alZ drwxr-xr-x. root root 
> >> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 . drwxr-xr-x. root root 
> >> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 .. -rw-r--r--. root root 
> >> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 httpd.conf -rw-r--r--.
> >> root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 magic [root@virt
> >> conf]# restorecon -R -v -F httpd.conf restorecon reset 
> >> /var/lib/libvirt/filesystems/container1/etc/httpd/conf/httpd.conf
> >> context 
> >>
> system_u:object_r:svirt_lxc_file_t:s0:c1,c2->system_u:object_r:virt_var_lib_t:s0
> >>
> >>
> >>
> >>
> >>  
- -- selinux mailing list selinux(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >> 
> > Right , is fixfiles onboot doing a force?  If it is, that is a  bug.
>  
>  I guess it is. I had to try fixfiles onboot because quotacheck kept 
>  creating aquota.user with the wrong type and i was denied access to restore
>  it ( turned out fixfiles onboot wasnt allowed it either ) we probably want
>  to make sure that quotacheck run by unconfined_t creates quota db files
>  with the proper context
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
It should although not everywhere.
 sesearch -T -s unconfined_t | grep quota_db_t
type_transition unconfined_t var_spool_t : file quota_db_t "aquota.group";
type_transition unconfined_t home_root_t : file quota_db_t "aquota.group";
type_transition unconfined_t usr_t : file quota_db_t "aquota.group";
type_transition unconfined_t mail_spool_t : file quota_db_t "aquota.user";
type_transition unconfined_t root_t : file quota_db_t "aquota.group";
type_transition unconfined_t home_root_t : file quota_db_t "aquota.user";
type_transition unconfined_t tmp_t : file quota_db_t "aquota.group";
type_transition unconfined_t tmp_t : file quota_db_t "aquota.user";
type_transition unconfined_t var_t : file quota_db_t "aquota.user";
type_transition unconfined_t mail_spool_t : file quota_db_t "aquota.group";
type_transition unconfined_t boot_t : file quota_db_t "aquota.group";
type_transition unconfined_t etc_t : file quota_db_t "aquota.user";
type_transition unconfined_t mqueue_spool_t : file quota_db_t "aquota.group";
type_transition unconfined_t var_spool_t : file quota_db_t "aquota.user";
type_transition unconfined_t root_t : file quota_db_t "aquota.user";
type_transition unconfined_t mqueue_spool_t : file quota_db_t "aquota.user";
type_transition unconfined_t var_t : file quota_db_t "aquota.group";
type_transition unconfined_t etc_t : file quota_db_t "aquota.group";
type_transition unconfined_t usr_t : file quota_db_t "aquota.user";
type_transition unconfined_t boot_t : file quota_db_t "aquota.user";


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlD12fsACgkQrlYvE4MpobO9hACg6yZRH/CtLkjD5FQg23JIQbRt
> Dy8AoOrR01PrDElo2Pdf4WbgvTzWifQx
> =mlye
> -----END PGP SIGNATURE-----

[Dominick Grift]

On Tue, 2013-01-15 at 17:36 -0500, Daniel J Walsh wrote:
>  On 01/15/2013 04:22 PM, Dominick Grift wrote:
>  > On Tue, 2013-01-15 at 15:54 -0500, Daniel J Walsh wrote:
>  >> On 01/15/2013 02:28 PM, Dominick Grift wrote:
>  >>> 
>  >>> On Tue, 2013-01-15 at 20:23 +0100, Dominick Grift wrote:
>  >>>> On Tue, 2013-01-15 at 10:10 -0500, Daniel J Walsh wrote:
>  >>>>> On 01/15/2013 10:03 AM, Dominick Grift wrote:
>  >>>>>> On Tue, 2013-01-15 at 09:58 -0500, Daniel J Walsh wrote:
>  >>>>>>> On 01/15/2013 09:15 AM, Dominick Grift wrote:
>  >>>>>>>> On Tue, 2013-01-15 at 14:11 +0100, Göran Uddeborg
> wrote:
>  >>>>>>>>> I'm running a "restorecon -n -R -v /"
> from cron once a
>  >>>>>>>>> month, just to be careful and know what is
> happening.  Last
>  >>>>>>>>> night when it ran, I got a lot of error messages
> like
>  >>>>>>>>> these:
>  >>>>>>>>> 
>  >>>>>>>>> restorecon:  Warning no default label for
> /dev/pts/3
>  >>>>>>>>> 
>  >>>>>>>>> and
>  >>>>>>>>> 
>  >>>>>>>>> restorecon:  Warning no default label for
>  >>>>>>>>> /tmp/efs0YYVa79.html
>  >>>>>>>>> 
>  >>>>>>>>> There were a couple for things in /dev, and lots of
> them
>  >>>>>>>>> for things in /tmp.
>  >>>>>>>>> 
>  >>>>>>>>> I have lately been upgrading bit by bit to Fedora 18
> (the 
>  >>>>>>>>> beta, strictly speaking, since the final release
> isn't 
>  >>>>>>>>> officially out at the time of this writing), so I
> assume
>  >>>>>>>>> the new message is related to these upgrades. But
> why?
>  >>>>>>>>> When I list file contexts, I see rules like this:
>  >>>>>>>>> 
>  >>>>>>>>> /dev/pts(/.*)?                                    
> all
>  >>>>>>>>> files <<None>>
>  >>>>>>>>> 
>  >>>>>>>>> So I guess it is not a simple mistake.  But what is
> the
>  >>>>>>>>> reason? Why don't some /dev entries, and almost
> the entire
>  >>>>>>>>> /tmp directory, have any default context any more?
>  >>>>>>>> 
>  >>>>>>>> It has to do with some optional security models like
> mcs, mls
>  >>>>>>>> and ubac and the nature of their security attributes i
>  >>>>>>>> believe
>  >>>>>>>> 
>  >>>>>>>> For example if you create a file in /tmp with a
> compartment
>  >>>>>>>> of s0:c23 then you do not want a relabel to reset it
> because
>  >>>>>>>> that would declassify the file back to s0
>  >>>>>>>> 
>  >>>>>>>> SELinux cannot determine that the file should be
> labeled
>  >>>>>>>> s0:c23 because a unprivileged user with access to the
>  >>>>>>>> compartment decided that
>  >>>>>>>> 
>  >>>>>>>> So by ignoring the context altogether you can be sure
> that
>  >>>>>>>> the file will not get declassified by
> restorecon/fixfiles
>  >>>>>>>> 
>  >>>>>>>> So you will see this in public places like /tmp etc.
>  >>>>>>>> 
>  >>>>>>>> There is a similar issue with types. Users may have some
>
>  >>>>>>>> discretion over select types to relabel to and from.
> SELinux 
>  >>>>>>>> cannot determine that a user decided to label from
> example
>  >>>>>>>> file ~/bla type httpd_user_content_t.
>  >>>>>>>> 
>  >>>>>>>> So with types there is a different approach: some types
> are 
>  >>>>>>>> declared customizable types. If a file has a
> customizable
>  >>>>>>>> type then SELinux will not try to relabel it (so that it
> wont
>  >>>>>>>> get unintentionally declassified) unless you use the -F
>  >>>>>>>> flag.
>  >>>>>>>> 
>  >>>>>>>> The identity field by default does not get reset unless
> one
>  >>>>>>>> uses restorecon with the -F flag
>  >>>>>>>> 
>  >>>>>>>> With MLS security models processes are forced to operate
> on 
>  >>>>>>>> specified security levels for the sake of enforcing 
>  >>>>>>>> confidentiality. Files that may be affected and are in
>  >>>>>>>> public places are not flagged to be reset with the
> <<None>>
>  >>>>>>>> 
>  >>>>>>>> Disclaimer: this is my understanding of the issue but i
> might
>  >>>>>>>> be wrong
>  >>>>>>>> 
>  >>>>>>>> 
>  >>>>>>>> 
>  >>>>>>>>> -- selinux mailing list
> selinux(a)lists.fedoraproject.org 
>  >>>>>>>>>
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>>>>>>> 
>  >>>>>>>> 
>  >>>>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org
>
>  >>>>>>>>
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>>>>>>> 
>  >>>>>>> Yes the basic idea is in certain directories like mnt_t,
>  >>>>>>> tmp_t, tmpfs_t we do not have a standard definition of
> content
>  >>>>>>> in these directories.  So <<none>> says any
> content could be
>  >>>>>>> here, so don't change the labels.  For example a user
> does cp
>  >>>>>>> -a ~/.ssh /tmp Would move ssh_home_t content to /tmp, if
> you
>  >>>>>>> ran restorecon on it and we had default label of tmp_t or
>  >>>>>>> user_tmp_t, then all apps could read tmp_t could not read
> the
>  >>>>>>> content.
>  >>>>>>> 
>  >>>>>>> Modern restorecon in RHEL7 and Latest Fedoras does not
> change
>  >>>>>>> any components of the security context other then the type
>  >>>>>>> field. unless you specify force. This is something we want
>  >>>>>>> avoid as we move forward with MCS labeling and MLS
> Labeling.
>  >>>>>>> If you use containers or static labeling for virtual
> machines,
>  >>>>>>> you do not want restorecon changing the MLS/MCS field.
>  >>>>>>> 
>  >>>>>>> The reason you are noticing this is we added an error check
> to 
>  >>>>>>> restorecon to tell the user that restorecon /mnt/foobar did
> not
>  >>>>>>> do anything.
>  >>>>>>> 
>  >>>>>>> restorecon -R /mnt
>  >>>>>>> 
>  >>>>>>> Will not output the error, since we wanted to quiet the
> noise,
>  >>>>>>> but if you get verbose, you will get the noise.  I guess we
>  >>>>>>> could add a -vv for realy verbose, if the message is
>  >>>>>>> aggravating.
>  >>>>>> 
>  >>>>>> By the way, we probably want to not relabel content in 
>  >>>>>> /var/lib/libvirt/filesystems.
>  >>>>>> 
>  >>>>>> I did a relabel and all my container contexts were reset
>  >>>>>> 
>  >>>>> Really, I don't see that
>  >>>>> 
>  >>>>> # restorecon -R -v /var/lib/libvirt/filesystems/ # ls -lZ 
>  >>>>> /var/lib/libvirt/filesystems/ drwxr-xr-x. root root 
>  >>>>> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 apache1 drwxr-xr-x.
>  >>>>> root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 container1
>  >>>>> drwxr-xr-x. root root
>  >>>>> system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 dan drwxr-xr-x. root
>  >>>>> root system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 myapache
>  >>>>> drwxr-xr-x. root root 
>  >>>>> system_u:object_r:svirt_lxc_file_t:s0:c0.c1023 mymysql
>  >>>>> 
>  >>>> 
>  >>>> I did see it but i did a fixfiles onboot
>  >>>> 
>  >>> 
>  >>> 
>  >>> # pwd /var/lib/libvirt/filesystems/container1/etc/httpd/conf
>  >>> [root@virt conf]# ls -alZ drwxr-xr-x. root root 
>  >>> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 . drwxr-xr-x. root root 
>  >>> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 .. -rw-r--r--. root root 
>  >>> system_u:object_r:svirt_lxc_file_t:s0:c1,c2 httpd.conf -rw-r--r--.
>  >>> root root system_u:object_r:svirt_lxc_file_t:s0:c1,c2 magic [root@virt
>  >>> conf]# restorecon -R -v -F httpd.conf restorecon reset 
>  >>> /var/lib/libvirt/filesystems/container1/etc/httpd/conf/httpd.conf
>  >>> context 
>  >>>
> system_u:object_r:svirt_lxc_file_t:s0:c1,c2->system_u:object_r:virt_var_lib_t:s0
>  >>>
>  >>>
>  >>>
>  >>>
>  >>> 
>  -- selinux mailing list selinux(a)lists.fedoraproject.org
>  >>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>  >>> 
>  >> Right , is fixfiles onboot doing a force?  If it is, that is a  bug.
>  > 
>  > I guess it is. I had to try fixfiles onboot because quotacheck kept 
>  > creating aquota.user with the wrong type and i was denied access to restore
>  > it ( turned out fixfiles onboot wasnt allowed it either ) we probably want
>  > to make sure that quotacheck run by unconfined_t creates quota db files
>  > with the proper context
>  > 
>  > 
>  > -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  > 
>  It should although not everywhere.
>   sesearch -T -s unconfined_t | grep quota_db_t
>  type_transition unconfined_t var_spool_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t home_root_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t usr_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t mail_spool_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t root_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t home_root_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t tmp_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t tmp_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t var_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t mail_spool_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t boot_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t etc_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t mqueue_spool_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t var_spool_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t root_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t mqueue_spool_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t var_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t etc_t : file quota_db_t "aquota.group";
>  type_transition unconfined_t usr_t : file quota_db_t "aquota.user";
>  type_transition unconfined_t boot_t : file quota_db_t "aquota.user";
>  
>   
Yes strange though that even though there is a transition and fc spec
that somehow still the file ended up with the wrong context. In the end
i just gave up and cheated a bit by disabling quota and then using chcon
the db files and then re-enabling quota without running quotacheck after
wards ( that would have probably changed the context again )

Whats even stranger is that on an other identical system quotacheck did
create it with the proper context (but there it was run by sysadm_t
instead of unconfined_t)

[mark]

Daniel J Walsh wrote:
<snip>
>  Modern restorecon in RHEL7 and Latest Fedoras does not change any
>  components of the security context other then the type field.  unless 
you specify
<snip>
Ah, so maybe that's why some of us are having issues, as we're running
CentOS 5 and 6, and haven't seen 6.4, much less the announcement of RHEL
7....

        mark

[Göran Uddeborg]

Thanks to both of you for the explanation!  Now I what is going on.

Dominick Grift:
>  So with types there is a different approach: some types are declared
>
>  customizable types. 
Is there some easy way to see what types are customizable?  I quickly
scanned the manual pages for seinfo, sesearch, and similar, but
couldn't find anything obvious.

Daniel J Walsh:
>  I guess we could add a -vv for realy
>  verbose, if the message is aggravating. 
Not for me!  As I indicated, I run this with both -v and -n just to
see what is going on.  The result is intended for manual inspection
and judgement.

The reason for the question was to understand, and I thank you for the
explanation.

If I would get irritated by the message, there is always sed. :-)

[Daniel J Walsh]

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

On 01/15/2013 03:47 PM, G￶ran Uddeborg wrote:
>  Thanks to both of you for the explanation!  Now I what is going on.
>  
>  Dominick Grift:
> > So with types there is a different approach: some types are declared 
> > customizable types.
>  
>  Is there some easy way to see what types are customizable?  I quickly 
>  scanned the manual pages for seinfo, sesearch, and similar, but couldn't
>  find anything obvious.
>  
>  Daniel J Walsh:
> > I guess we could add a -vv for realy verbose, if the message is
> > aggravating.
>  
>  Not for me!  As I indicated, I run this with both -v and -n just to see
>  what is going on.  The result is intended for manual inspection and
>  judgement.
>  
>  The reason for the question was to understand, and I thank you for the 
>  explanation.
>  
>  If I would get irritated by the message, there is always sed. :-)
>   
cat /etc/selinux/targeted/contexts/customizable_types
sandbox_file_t
svirt_image_t
svirt_home_t
svirt_lxc_file_t
virt_content_t
httpd_user_htaccess_t
httpd_user_script_exec_t
httpd_user_rw_content_t
httpd_user_ra_content_t
httpd_user_content_t
git_session_content_t
home_bin_t
user_tty_device_t

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlD1wT4ACgkQrlYvE4MpobPLKgCfcrId12QbnFQPeCuzerSebZNm
> 9/cAoL5zS0+IrxVWQIKyG4QBLMfo1zXZ
> =/cqc
> -----END PGP SIGNATURE-----

[Göran Uddeborg]

>  cat /etc/selinux/targeted/contexts/customizable_types 
Ah, that easy! :-)

[Dominick Grift]

On Tue, 2013-01-15 at 21:47 +0100, Göran Uddeborg wrote:
>  Thanks to both of you for the explanation!  Now I what is going on.
>  
>  Dominick Grift:
>  > So with types there is a different approach: some types are declared 
>  > customizable types.
>  
>  Is there some easy way to see what types are customizable?  I quickly
>  scanned the manual pages for seinfo, sesearch, and similar, but
>  couldn't find anything obvious. 
# cat /etc/selinux/targeted/contexts/customizable_types
sandbox_file_t
svirt_image_t
svirt_home_t
svirt_lxc_file_t
virt_content_t
httpd_user_htaccess_t
httpd_user_script_exec_t
httpd_user_rw_content_t
httpd_user_ra_content_t
httpd_user_content_t
git_session_content_t
home_bin_t
user_tty_device_t