using selinux to control user access to files

Stephen Smalley sds at tycho.nsa.gov
Mon May 9 12:38:55 UTC 2005


On Mon, 2005-05-09 at 13:29 +0200, Hein Coulier wrote:
> thx for the feedback Stephen, but i'm still unable to succeed,
> i'm also getting some strange errors, so perhaps my installed policy isn't a
> good one to start with :
> # rpm -qa selinux-policy-targeted-sources
> 
> selinux-policy-targeted-sources-1.17.30-2.52.1

Yes, if you want to have user roles and domains, you need strict policy.
targeted policy lacks the infrastructure for user roles and domains; it
only knows about daemons.

> # rpm -qa|grep -i release
> 
> redhat-release-4AS-2

Ah, unfortunately RHEL4 didn't ship with a strict policy included.
You can take it up with your Red Hat support person, or grab the
selinux-policy-strict* packages from Fedora Core (in the latter case,
you will likely want to also upgrade your other SELinux-related
packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel,
checkpolicy, policycoreutils, setools, setools-gui).

> # define domains
> 
> type domainA_t, domain, file_type;
> 
> type domainB_t, domain, file_type;
> 
> type domainC_t, domain, file_type;

full_user_role() defines both a role and an initial domain for the role
using the same prefix, so you don't need to separately define the
domains here.  Also, 'file_type' doesn't belong on domains.  Domains are
for processes, file types are for files.

> allow       domainA_t     typeA_t:file r_file_perms;
> 
> auditallow  domainB_t     typeB_t:file r_file_perms;
> 
> auditallow  domainC_t     typeC_t:file rw_file_perms;

You would need allow rules as well for the latter domains; auditallow
just says "audit when allowed", so you need both an allow rule and an
auditallow rule in order to both allow the action and enable auditing of
it when allowed.

> # junk to tackle make-errors

This is because targeted policy lacks the infrastructure for user
domains.

> # create roles
> 
> full_user_role(roleA);
> 
> full_user_role(roleB);
> 
> role roleA_r types {domainA_t unconfined_t};
> 
> role roleB_r types {domainA_t domainB_t domainC_t unconfined_t};

full_user_role(X) should define a X_r role as well as a X_t domain as
the initial domain for the role, and authorize the role for the domain.
So you don't need to separately define domains and authorize the role
for it.   E.g. full_user_role(A) would create role A_r and type A_t, and
authorize role A_r for A_t.

> i also have a silly question, in a security context (eg
> user_u:object_r:typeA_t), what is the mening of user_u ?

It is a generic user identity used when the SELinux policy does not
define a separate user identity for the Linux username.  This is useful
if you have a large number of users who do not need separation via
SELinux, e.g. so you can map all unprivileged users to user_u and not
need to maintain them in the policy individually.

-- 
Stephen Smalley
National Security Agency




More information about the fedora-selinux-list mailing list