I quickly summarized what is happend so far.
Requirements from issue #51  in Github:
- 20000 rules in policy
- 600 SMACK labels
- We have hash based dictionary for SMACK labels already implemented.
- Support for detecting and writing multiple rules  is lacking.
- Rule set is not optimized in any possible way. It's just a
a linear list.
This is my plan to move forward:
- Keep label management as it is.
- Multiple rules handling must be implemented. Rafal, you are working
on this right?
- Rules should be always merged.
My decision as is to take one implementation to the end and therefore
integrate code for merging labels in Github issue #87 .
If you ever encounter a real-world workload that causes problems
with that approach, we can take it into discussion here in this
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.
My proposal is for complex detection of kernel features during library initialization with result stored in an internal, global variable (e.g. feature bitmask). 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.
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).
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.
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)
* Support for multi-rule write to load2 and change-rule (kernel 3.12)
* Maximum value for CIPSO category change from 63 to 184 (kernel 3.12)
* Transmute access mode (kernel 2.6.38)
Now that we have this mailing list ramped up, I'm strongly considering
moving from Github to traditional patch management process where:
- Patches are prepared with git format-patch with possible cover (00)
letter if it is a patch series.
- Patches are sent using git send-email (well, you can use mutt or whatever
as long as it doesn't break the patch file).
- I'll merge accepted patches with git am.
For me pull requests bring overhead to the maintenance because I anyway
do all the patch integration from command-line. I believe that using pull
requests also decrease developer efficiency.
Issues can be still be used for bug reports and such.