-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stephen Smalley wrote:
> On Wed, 2008-04-30 at 08:18 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Tue, 2008-04-29 at 13:29 -0400, Daniel J Walsh wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Christopher J. PeBenito wrote:
>>>>> For those interested all of the user roles have been separated out into
>>>>> individual modules in a new roles refpolicy layer, in refpolicy trunk.
>>>>> This should enable interested users to add and remove roles more easily.
>>>>> Each of the user roles has a module named after it (e.g., sysadm module
>>>>> for sysadm_r), except user_r, which has a name unprivuser, since its not
>>>>> possible to use "user" as a module name since it is a policy keyword.
>>>>>
>>>>> Next we will be doing an experiment attempting to use the SELinux RBAC
>>>>> functionality to separate users instead of SELinux TE. What this means
>>>>> is that the role field will start being used more substantially than it
>>>>> currently is. In a nutshell, this means that all user objects will have
>>>>> the user's role rather than object_r. Then the separate types will be
>>>>> collapsed into one type where possible. This will result in per-role
>>>>> types (e.g., user_mozilla_t, staff_mozilla_t) collapsing too
>>>>> (mozilla_t).
>>>>>
>>>>> So for example, all of the home directory types will be collapsed into
>>>>> home_t and home_dir_t. This results in /root having the context
>>>>> root:sysadm_r:home_dir_t.
>>>>>
>>>>> My current idea for RBAC rules is to group object classes in RBAC
>>>>> constraints similar to the current MLS constraints (e.g. file classes
>>>>> together, network classes together). The basic RBAC rule will be:
>>>>>
>>>>> constrain { dir file ... } { getattr read write .... }
>>>>> r1 == r2
>>>>> or r1 == system_r
>>>>> or r2 == object_r
>>>>> or r1 == rbac_subj_role_file_exempt
>>>>> or r2 == rbac_obj_role_file_exempt
>>>>> or t1 == rbac_subj_type_file_exempt
>>>>> or t2 == rbac_obj_type_file_exempt;
>>>>>
>>>>> Is this too coarse? Do we want to break it down into read and write
>>>>> rather than just exempt?
>>>>>
>>>>> Unfortunately this necessitates some kernel and userspace changes:
>>>>>
>>>>> Roles aren't respected on objects in the kernel. So if you create a
>>>>> file in a directory that has the role staff_r, the file will have an
>>>>> object_r role instead of staff_r.
>>>>>
>>>>> Login programs and newrole will have to be changed to set the role on
>>>>> the terminal.
>>>>>
>>>>> The above example rule utilizes a role attribute, which doesn't exist.
>>>>> In the absence of role attributes, role dominance can be used, but its
>>>>> unclear if the dominance code works, since no one uses it.
>>>>>
>>>>> Genhomedircon may need to be updated.
>>>>>
>>>>> Tools such as audit2allow will need more audit2why-like support and
>>>>> policy info to fix RBAC denials (a general constraints usability issue).
>>>>>
>>>>> Comments?
>>>>>
>>>> As has been stated before, I am not interested in separation of the
>>>> homedir based on Role, since this will prevent shared homedirs on
>>>> machines where the same user has different roles. Also makes testing of
>>>> homedir roles difficult since changing a role requires a full relabel of
>>>> the homedir. Labeling of the /root directory should be static and not
>>>> related to user or role, because domains often want read/write access to
>>>> the root directory and dontauditing this becomes complex if this changes
>>>> based on semanage rules.
>>>>
>>>> service XYZ start in /root will almost always generate a search of the
>>>> /root directory.
>>>>
>>>> Currently Fedora labeling on the homedir is user_home_t or
>>>> user_mozilla_home_t, Ie everything user_* So switching this to
>>>> mozilla_home_t or home_t would be fine.
>>> As before, I don't believe any of this would force anyone to separate
>>> files based on role; it would be driven by policy configuration and
>>> using object_r pervasively would continue to work fine. It would just
>>> offer the ability to provide such separation based on role if so
>>> configured, and it would drop the use of derived types to achieve such
>>> separation.
>>>
>>> If you aren't going to separate files based on role though, you may want
>>> to think about how to protect roles against influence by other roles so
>>> that e.g. user_r or staff_r cannot inject commands to be run by sysadm_r
>>> into dotfiles. DAC will help you with user-based separation (somewhat),
>>> but there is still the case where you have a user who is authorized for
>>> staff_r and sysadm_r who logs in initially in staff_r and later switches
>>> to sysadm_r. There you have consider the potential of a flawed or
>>> malicious program run while in staff_r trying to inject commands to be
>>> run in sysadm_r, all running under the same user identity.
>>>
>> I label /root admin_home_t and don't allow any confined role to write to
>> it. I have sysadm_r but have written before that I think it is a waste
>> of time, and prefer to just use unconfined_r.
>>
>> My view of the world is that you have a "login" role and you have an
>> "admin" role. On my machine this is staff_r and unconfined_r, respectively.
>
> Right, but whether unconfined_r or sysadm_r, the question is how to
> protect the more-privileged role (unconfined_r in your case) from
> influence by the less-privileged login role (staff_r) when they both
> operate under the same DAC uid and thus share the same set of dotfiles.
> The per-role types or roles on home directory files are one mechanism
> for achieving that protection. Another way would be to polyinstantiate
> the home directories by role. Another way that relies on DAC-only would
> be to create a dedicated (pseudo) user account for each role with its
> own home directory and "safe" set of dotfiles and switch to that account
> when switching roles.
>
But you are assuming the UID does not change. Since I look at the
world as Two Roles, One Role when I am normal user and another role
when I am root. I don't have this problem. I don't want users using
newrole, I want them to use sudo. So unconfined_t or webadm_t when
UID==root, staff_t when UID=dwalsh. newrole is just a complexity that
most users do not understand. Since a confined application can not
read by default the directories of the user, the user will not be able
to effect the confined domain.
>> If I want to run a confined role say webadm_r, I would not allow
>> webadm_r to touch any files in /root, so I don't see that I need
>> protection. Similarly webadm_r can not touch entries in the Homedir so
>> it can not attack other roles. If you need to create an admin role
>> which administrates more then one confined domain, then you would
>> generate a new admin role or enhance an existing admin role. For
>> example if you want to allow the webadm_r:webadm_t to be able to admin
>> mysql, you simply create a policy module with
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkgYkZMACgkQrlYvE4MpobMrEACfS7ahpKcJAaloLlHknRryJ5h9
w24AoLzWVBkSRoY9o8c6IxN8sjLITRbz
=Jo3o
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
