Hi, While working on my own policy, I've come across the glblub mode for defaultrange. It almost does what I need, but not quite. So I wanted to ask if a patch for a new "glblub2" (with a different name) mode has potential to be accepted: glblub current behavior: For the new context low level use the greatest intersection of source and target sensitivity and the lowest intersection of categories. For the new context high level use the lowest intersection of source and target level. or in pseudo code: context_new.low.sens = max(source.low.sens, target.low.sens) context_new.low.cats = and(source.low.cats, target.low.cats) context_new.high.sens = min(source.high.sens, source.high.sens) context_new.high.cats = and(source.low.cats, target.high.cats) glblub2, what I want: For the new context low level use the greatest intersection of source and target low level. For the new context high level use the lowest intersection of source and target high level. or in pseudo code (not the change to context_new.low.cats): context_new.low.sens = max(source.low.sens, target.low.sens) context_new.low.cats = or(source.low.cats, target.low.cats) context_new.high.sens = min(source.high.sens, source.high.sens) context_new.high.cats = and(source.low.cats, target.high.cats) A bit longer explanation why I need it: My policy only uses categories, no sensitivities, with the low level for confidentiality and the high level as integrity. A non-exhaustive list of rules: * A process can only transition to a lower-or-equal integrity level and a higher-or-equal confidentiality level. * A process may only execute a file it the files integrity level is higher-equal than the processes integrity level * A process can be trusted with information that has a confidentiality level that is dominated by its integrity level The confidentiality requirement for process transitions hasn't really been implemented, and I'm debating leaving it out, but by default a process should not drop his confidentiality level to prevent accidents, as glblub would do: glblub: process s0:c1-s0:c1.c5 executes file s0:c2-s0:c2.c3 resulting in process s0-s0:c2.c3 glblub2: process s0:c1-s0:c1.c5 executes file s0:c2-s0:c2.c3 resulting in process s0:c1.c2-s0:c1.c3 A more practical example (low = s0, high = s0:c0.c5): Consider /bin/bash a file with no confidentiality but the highest integrity: /bin/bash low-high Executing bash is fine, and should result in just low-high ; no requirement to keep bash secret and bash can't be modified by someone who isn't already x-high. If a user (low-high) executes a script in a project that e.g. was marked with some integrity and some confidentiality the process should range transition by default (and maybe enforced by constraints as set out above): /home/abc/myproject/abc.sh s0:c1-s0:c1.c3 executing abc.sh should result in s0:c1-s0:c1.c3 This ensures that no process without c1 could access any information about "myproject" by accident, and that "myproject" can't compromise the integrity of other processes (e.g. with c4). If nobody stops me then I'll submit a patch once I've got some time again to work on this. -- bauen1 https://dn42.bauen1.xyz/
