Russell Coker wrote:
> Currently we don't support ranges on files, but we can change policy
> to allow it. You could have something like the following:
>
> mlsconstrain file { read }
> (( h1 dom l2 ) or ( t2 == domain ) or ( t1 == mlsfileread ));
>
> mlsconstrain file { create relabelto }
> (( h1 dom h2 ) and ( l1 dom l2 ));
Hello,
thanks for the tip. Actually I had the same idea yesterday! Only that I
thought of
mlsconstrain file { create relabelto }
(( h1 dom h2 ) and ( h1 dom l2 ));
^
because in my MCS schema users usually have low = s0.
What exactly do you mean by not supporting ranges on files? Normally MCS
has a constrain on create/relabelto such as h2 eq l2, but I think if the
constrain is relaxed in the abovementioned fashion then there would be
no other problems? (I have seen multiranged files in the MLS policy...)
> But generally read-only files are implemented with new types. I do
> that on the custom policy for my SE Linux Play Machine.
Well, what I want is to give users one login that maps to a generic
identity (say, user_u), but control their access to file of various
projects via MCS categories.
Now, if I had read only and read/write TE rules, I can imagine giving
every user 2 accounts, of which one would result in a shell that is
confined to read only operations, but has more MCS cats, but I can't
imagine how would I accomplish that with one account.
Or I could create a separate selinux user for everyone and by some
wicked macro machinery give that user the appropriate TE types and rules
for every project, but that seems to me like a lot of mess and generally
asking for trouble.
Regards,
Michal Svoboda
Attachment:
pgp1gfWmtqjPH.pgp
Description: PGP signature
