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
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.
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 }").
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 }").