Casey Schaufler wrote:
--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
Casey Schaufler wrote:
<snip>
Smack provides mandatory access controls based on the label attached
to a task and the label attached to the object it is attempting to
access. Smack labels are deliberately short (1-7 characters) text
strings. Single character labels using special characters are reserved
for system use. The only operation applied to Smack labels is equality
comparison. No wildcards or expressions, regular or otherwise, are
used.
A file always gets the Smack label of the task that created it.
Smack defines and uses these labels:
"*" - pronounced "star"
"_" - pronounced "floor"
"^" - pronounced "hat"
"?" - pronounced "huh"
The access rules enforced by Smack are, in order:
1. Any access requested by a task labeled "*" is denied.
2. A read or execute access requested by a task labeled "^"
is permitted.
3. A read or execute access requested on an object labeled "_"
is permitted.
4. Any access requested on an object labeled "*" is permitted.
5. Any access requested by a task on an object with the same
label is permitted.
6. Any access requested that is explicitly defined in the loaded
rule set is permitted.
7. Any other access is denied.
Rules may be explicitly defined by writing subject,object,access
triples to /smack/load.
Smack rule sets can be easily defined that describe Bell&LaPadula
sensitivity, Biba integrity, and a variety of interesting
configurations. Smack rule sets can be modified on the fly to
accomodate changes in the operating environment or even the time
of day.
How exactly can you describe a blp policy with this module?
Example below. Actually, you chose the absolute worst case example
in a fully populated Bell&LaPadula sensitivity scheme. But real
world experiance is that MLS systems very rarely use both levels
and categories. A small number use just levels, which could be
represented thus:
TS:SBI TS rx
TS:SBI S rx
TS:SBI C rx
TS:SBI U rx
TS S rx
TS C rx
TS U rx
S C rx
S U rx
C U rx
Disregarding the belief some of us hold about the usefulness of a blp
policy in general(*), the capabilities you are providing with this
security module and the surrounding infrastructure make the situation
worse. It appears that users can only have 1 label each, there is no
facility for changing labels of your user session, etc. I respect your
intention to make this as minimal as possible but I just don't see
anyone ever using it as is.
* blp is useful in some situations, I'll grant. One of those (few)
situations is a CMW. Neglecting whether or not a CMW's are a good idea
anyway your system won't be able to create an effective CMW due to the
lack of infrastructure including trusted X support, multiple
simultaneous user session labels, etc. It wouldn't even be able to be a
multilevel fileserver without labeled nfs support. So, I'll repeat my
question, do you have any *actual* use cases where this will solve an
*actual* security problem.
and the majority use just categories, which requires no specification
at all to provide separation.
Except it won't provide real dominance relationships so everyone will be
able to access their own category only. This is obviously non-ideal, not
in the spirit of category systems and again, not useful.
How do you
define dominance relationships between levels and over categories
without a very complex policy?
It's simple, but to do the full permutation set, not small.
That is silly. In those terms SELinux is simple (allow foo_t bar_t :
file read). It is only a tiny bit more verbose than your language and
provides object class granularity, yet everyone claims SELinux is
complex because of the policy size, the same goes for your statement above.
Let's say we want TS, S, and U for levels, with
categories A and B. The specification would be:
TS/A,B TS/A rx
TS/A,B TS/B rx
TS/A,B TS rx
TS/A,B S/A rx
TS/A,B S/B rx
TS/A,B S rx
TS/A,B U/A rx
TS/A,B U/B rx
TS/A,B U rx
S/A,B S/A rx
S/A,B S/B rx
S/A,B S rx
S/A,B U/A rx
S/A,B U/B rx
S/A,B U rx
U/A,B U/A rx
U/A,B U/B rx
U/A,B U rx
TS/A TS rx
TS/A S/A rx
TS/A S rx
TS/A U/A rx
TS/A U rx
S/A S rx
S/A U/A rx
S/A U rx
U/A U rx
TS/B TS rx
TS/B S/B rx
TS/B S rx
TS/B U/B rx
TS/B U rx
S/B S rx
S/B U/B rx
S/B U rx
U/B U rx
TS S rx
TS U rx
S U rx
I'm not saying that the preceeding is pretty, but it isn't complicated.
Yes, and the policy gets exponentially worse every time you add a level
or category, not an ideal situation for supposedly "simple" MLS
implementations.
My main concern is that I don't see any real security goals or use cases
that this can address, can you provide some use cases that make this a
viable security mechanism?
Well, there's Bell and LaPadula in the common category usage, the
occasional level usage, and the rare full level+cats scheme.
Biba integrity is easy as well, just scroll back to the example and
turn your monitor upside down.
I am seriously dubious about the ability for this module to provide a
working system with a Biba policy, but maybe thats just me :)
Another serious use is time based policy:
at 5pm:
# echo 'worker game x' > /smack/load
at 8am:
# echo 'worker game -' > /smack/load
Those are simple examples of some of the more obvious uses.
Its a possibly interesting use case. I'm curious about this kind of
'overriding' of rules though, how does one see the currently effective
policy?
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
