Thank you for your input,
In my original email I wanted to explain my model a bit more but ultimately did not, since it would distract from the issue.
On 8/4/20 6:56 PM, Joshua Brindle wrote:
> On Sun, Aug 2, 2020 at 5:20 AM bauen1 <j2468h@xxxxxxxxxxxxxx> wrote:
>>
>> Hello,
>>
>> The user level is currently used as the range for files under HOME_DIR.
>> It appears that the Bell-LaPadula model makes the assumption that all objects are single leveled, this assumption is also made in libsepol. (I haven't really found a good source for this assumption)
>>
>
> libsepol does not make any assumptions about policy. Everything is
> defined in the policy mls or mcs files in terms of constraints.
In my opinion libsepol should not make any assumptions about the policy, and usually it doesn't.
However currently the "user level" is used as the range component for file labels containing HOME_DIR (and similiar).
libsepol and the binary policy limits the "user level" to a level instead of a range, this makes it very hard to use ranges for home files by default.
I would like to change this, but I'm not really sure how backwards compatibility should be handled and if there would be a better term for "user level" that doesn't contain "level".
>> But in my own (MCS) policy objects are not single leveled.
>
> Files are, by definition, single level objects because they cannot be
> decomposed. A file with U - TS data in it is a TS file.
My policy doesn't really follow the standard MLS / MCS model.
So far I have found using "confidentiality" for the low and "integrity" for the high level to be the most fitting.
For example a semi-secret file (low = s0:c1) was created by a subject with more access (high = s0:c1,c2).
The integrity level of a file can then be used to check if the subject that created it stands to gain something.
E.g. an admin with access to just category 1 edits a file that is read (and executed) by a daemon with access to category 1-3.
> The policy (not libsepol) handles enforcing single-level objects, for
> example in refpolicy:
>
> # make sure these file classes are "single level"
> mlsconstrain { file lnk_file fifo_file } { create relabelto }
> ( l2 eq h2 );
>
> You cannot create or relabel a file with anything other than low = high.
>
> Directories can be ranged, if they contain files of multiple levels,
> again, from refpolicy:
> # Directory "write" ops
> mlsconstrain dir { add_name remove_name reparent rmdir }
> (( l1 eq l2 ) or
> (( t1 == mlsfilewriteinrange ) and ( l1 dom l2 ) and ( l1
> domby h2 )) or
> (( t1 == mlsfilewritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
> ( t1 == mlsfilewrite ) or
> ( t2 == mlstrustedobject ));
>
> So the source low must equal the directory low or one of the mls
> exception attributes controls fine grained usage.
Thanks for pointing this out, I will need to look into this a bit more.
>> Read (and process communication) operations are allowed if a processes high level dominates an objects low level.
>> Write operations are allowed if a processes high level dominates an objects high level.
>>
>> Later I've found that someone else had also come up with this idea independently, see https://lore.kernel.org/selinux/20091103114530.GH1672@xxxxxxxxxxxxxxxxxxx/ and https://lore.kernel.org/selinux/20091125202727.GD1649@xxxxxxxxxxxxxxxxxxx/ .
>>
>> For this I want to label files under HOME_DIR with the range user_lowest-user_highest.
>> Ignoring process communication this would prevent a login with less than maximum clearance from escalating by writing to e.g. ~/.bashrc .
>>
>> For example a user with the range s0-s0:c0.c3 would have his home files labeled as s0-s0:c0.c3.
>> A local tty login with the maximum clearance s0-s0:c0.c3 would be able to edit ~/.bashrc .
>> But an ssh login from e.g. an insecure network with only the range s0-s0:c1 would be able to read but not write important files such as ~/.bashrc .
>>
>> Using user_highest-user_highest as user level would force the user to correct the context of potentially a lot of files required by whatever is run with less than user_highest high, so I want to avoid this.
>>
>> Would it make sense to change libsepol to accept a range as user level (and perhaps changing the name) ?
>
> libsepol isn't really doing anything here. You can use semanage to set
> a file context, something like:
See above, libsepol is responsible for the limitation of the user level to a level, everything else doesn't have this limitation.
> # semanage fcontext -r s0-s0:c0.c3 /home/username
> # restorecon -R /home/username
Yes, but this doesn't really scale too well.
> But you do need to be careful of escalation as you've noted, you may
> need a number of these to set specific files to the user high level
--
bauen1
https://dn42.bauen1.xyz/
