[refpolicy] What is security_file_type and auth_file_type?

[refpolicy] What is security_file_type and auth_file_type?

[Sven Vermeulen]

Hi all

Originally, the use of the security_file_type attribute was to reduce the
size of the policy, and its purpose was mainly to differentiate between
files that could be dontaudited and those that couldn't (we want to see when
user domains access security_file_type types that they do not have access
to).

However, I could not find what the scope should be for a security_file_type
(and auth_file_type). When should a type be assigned to be a
security_file_type? "security" is a broad term...

Is it types that could jeopardize the security (confidentiality? integrity?
availability?) of the system when the resources of that type are /read/ by
unauthorized domains? Or is it when the resources are written to? The latter
(writes) is of course much broader (writing to /etc/pam.d or to the libraries
on the system for instance).

Wkr,
	Sven Vermeulen

[refpolicy] What is security_file_type and auth_file_type?

[Daniel J Walsh]

On 12/21/2014 05:11 AM, Sven Vermeulen wrote:
> Hi all
>
> Originally, the use of the security_file_type attribute was to reduce the
> size of the policy, and its purpose was mainly to differentiate between
> files that could be dontaudited and those that couldn't (we want to see when
> user domains access security_file_type types that they do not have access
> to).
>
> However, I could not find what the scope should be for a security_file_type
> (and auth_file_type). When should a type be assigned to be a
> security_file_type? "security" is a broad term...
>
> Is it types that could jeopardize the security (confidentiality? integrity?
> availability?) of the system when the resources of that type are /read/ by
> unauthorized domains? Or is it when the resources are written to? The latter
> (writes) is of course much broader (writing to /etc/pam.d or to the libraries
> on the system for instance).
>
> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
I see security_file_type as being the type associated with types that
should not be READ, not written.
/etc/shadow and friends. 

 seinfo -asecurity_file_type  -x
   security_file_type
      selinux_config_t
      default_context_t
      dnssec_t
      shadow_t
      krb5_keytab_t
      selinux_login_config_t
      file_context_t
      audit_spool_t
      semanage_store_t
      auditd_etc_t
      auditd_log_t
      random_seed_t

Although a couple of these (selinux config types) should probably not be
included.  

[refpolicy] What is security_file_type and auth_file_type?

[Sven Vermeulen]

On Mon, Dec 22, 2014 at 09:23:42AM -0500, Daniel J Walsh wrote:
> I see security_file_type as being the type associated with types that
> should not be READ, not written.
> /etc/shadow and friends. 
> 
>  seinfo -asecurity_file_type  -x
>    security_file_type
>       selinux_config_t
>       default_context_t
>       dnssec_t
>       shadow_t
>       krb5_keytab_t
>       selinux_login_config_t
>       file_context_t
>       audit_spool_t
>       semanage_store_t
>       auditd_etc_t
>       auditd_log_t
>       random_seed_t
> 
> Although a couple of these (selinux config types) should probably not be
> included.  

So things like private keys and passwords (or password containing files) I
can understand. Why would auditd related files be considered to be "not
readable"? What leaks/problems do you see with access to those files that
are so severe?

Wkr,
	Sven Vermeulen

PS At least you can still query which types have security_file_type set.
   With the 2.4 userspace if the attribute is not directly used in rules,
   then it is no longer part of the policy:

   ~# seinfo -asecurity_file_type -x
   ERROR: Provided attribute (security_file_type) is not a valid attribute
   name.

   This is because the security_file_type is used for /excluding/ those
   types from rules (like "{ file_type -security_file_type }").

[refpolicy] What is security_file_type and auth_file_type?

[Daniel J Walsh]

On 12/23/2014 12:14 PM, Sven Vermeulen wrote:
> On Mon, Dec 22, 2014 at 09:23:42AM -0500, Daniel J Walsh wrote:
>> I see security_file_type as being the type associated with types that
>> should not be READ, not written.
>> /etc/shadow and friends. 
>>
>>  seinfo -asecurity_file_type  -x
>>    security_file_type
>>       selinux_config_t
>>       default_context_t
>>       dnssec_t
>>       shadow_t
>>       krb5_keytab_t
>>       selinux_login_config_t
>>       file_context_t
>>       audit_spool_t
>>       semanage_store_t
>>       auditd_etc_t
>>       auditd_log_t
>>       random_seed_t
>>
>> Although a couple of these (selinux config types) should probably not be
>> included.  
> So things like private keys and passwords (or password containing files) I
> can understand. Why would auditd related files be considered to be "not
> readable"? What leaks/problems do you see with access to those files that
> are so severe?
I can see the audit_log_t files and perhaps files that MLS folks
classify as SystemHigh.  The audit config, should not be considered a
security_file_type.  Bottom line is we should define this type.  I think
files that potentially contain system secrets would be appropriate and
then remove the type from other files.
> Wkr,
> 	Sven Vermeulen
>
> PS At least you can still query which types have security_file_type set.
>    With the 2.4 userspace if the attribute is not directly used in rules,
>    then it is no longer part of the policy:
>
>    ~# seinfo -asecurity_file_type -x
>    ERROR: Provided attribute (security_file_type) is not a valid attribute
>    name.
>
>    This is because the security_file_type is used for /excluding/ those
>    types from rules (like "{ file_type -security_file_type }").