On 1/23/2014 10:45 AM, Rafał Krypa wrote:
Following up discussion on Github issue #40 ("Backward
compatibility with kernel Smack interfaces is incomplete") I'd like to bring up
some ideas that I still have on this.
There are some kernel features that can be present on the kernel with Smack, but might be
missing. Some of them are detected at runtime by libsmack (i.e. long label support). Some
of them aren't. I'd like to propose an alternative approach for such detection.
Current approach chosen by Jarkko seem to be delaying the detection until it's really
needed. This means that until smackfs interfaces are actually opened, libsmack assumes
that all features are present. When actual interfacing when kernel is needed, libsmack
checks for support and fails if it's not
there. If it's possible, it tries to fall back to an older interface. Results of such
detection are not remembered and it will be repeated each time when needed.
This is actually the most efficient approach in most cases.
Most programs that use libsmack use it to get or set one value.
Why bother to remember state that you will never care about again?
I can see some value in remembering fall-back behavior for those
few interfaces that:
1. get called repeatedly in a program (/sys/fs/smackfs/access2)
and
2. have alternative interfaces (/smack/load, /sys/fs/smackfs/load2)
My proposal is for complex detection of kernel features during
library initialization with result stored in an internal, global variable (e.g. feature
bitmask).
This would introduce unnecessary overhead for programs like id.
Later on run time libsmack would be able to use that information to
make decisions earlier. For example it would be possible to fail right
away inside smack_accesses_add() when a long label is given and kernel doesn't
support it.
This would be simple to optimize. Keep track of whichever path open succeeds
and on subsequent opens go directly to the one known to exist. If that fails
you can bet there has been an inappropriate unmount.
This optimization would speed up the backward compatibility case without
impacting programs that don't use this function. It won't impact the common
case, which is that the kernel is up to date, either.
To allow policy preparation systems with no Smack support or simply
with smackfs temporarily unmounted, I suggest assumption that missing smackfs is
equivalent to having all features enabled. That would work on functions that don't
need direct access to Smack in kernel (smack_accesses_new =>
smack_accesses_add => smack_accesses_save).
That is not the assumption i would expect. I don't see a lot of value
in having libsmack on a system without Smack, and the few things that
could work would have to be used in a contrived way.
I have prepared an initial patch moving existing runtime detection to
init.c and using this information in the library. With this infrastructure it would be
possible to add detection of several other features, that aren't detected right now.
I have however waited too long with my patch and Jarkko has moved in another direction. I
specifically mean patch d7319c7 ("libsmack: add a common function for opening long
and short label file"), which emphasizes late detection. Therefore I'd like to
ask for opinions on the mailing list and check
if I can still convince you to the alternative way.
I don't think that optimization of libsmack in support of
deployment on older kernel versions is worth putting any effort
into. The functions in libsmack just don't get called that
often.
Finally here are additional the kernel features that I'd like to
detect. Checking for these will require opening of smackfs files and reading/writing to
them to make detection possible. This in my opinion is an argument for running detection
only once per process run time.
* Lock access mode (kernel 3.13)
How will you detect this without creating a potentially harmful access rule?
* Support for multi-rule write to load2 and change-rule (kernel
3.12)
How will you detect this without creating a potentially harmful access rule?
* Maximum value for CIPSO category change from 63 to 184 (kernel
3.12)
How will you detect this?
* Transmute access mode (kernel 2.6.38)
How will you detect this without creating a potentially harmful access rule?
Best regards,
Rafal Krypa
_______________________________________________
SMACK-discuss mailing list
SMACK-discuss(a)lists.01.org
https://lists.01.org/mailman/listinfo/smack-discuss