On Tue, Nov 21, 2023 at 7:29 AM Juraj Marcin <juraj@xxxxxxxxxxxxxxx> wrote: > > Currently, filename transitions are stored separately from other type > enforcement rules and only support exact name matching. However, in > practice, the names contain variable parts. This leads to many > duplicated rules in the policy that differ only in the part of the name, > or it is even impossible to cover all possible combinations. > > This patch changes the filename transition table in the policydb > structure into an array of three tables, where the index determines the > match type for the rules contained (extract, prefix, and suffix match). > Then the patch extends the functions that access the table through the > policydb structure to accompany this change while reusing the majority > of the old filename transitions code. > > This patch also updates the code responsible for finding the right > filename transition based on the context and the name. The rules have > the following order of prioriy, if no matching rule is found, the code > moves on to the next category: > - exact filename transitions, > - prefix filename transitions in the order of the longest prefix match, > - suffix filename transitions in the order of the longest suffix match. > This ensures the compatibility with older policies. > > Without prefix/suffix rules in the policy, this patch has no impact on > performance or policy loading times. Moreover, with prefix/suffix rules, > the overall number of filename transitions can be reduced, which results > in smaller binary policy size and therefore also slightly lower load > time and memory usage. > > Performance tests: > > 1: Reference kernel (f5bbdeda34c63), Fedora policy (format v33) > 2: This patch, Fedora policy (format v33) > 3: This patch, Fedora policy without prefix/suffix rules (format v34) > 4: This patch, Fefora policy with prefix rules (format v35) > > | Mem | Binary | Policy | Create tty [1] | osbench [2] > | Usage | policy | load | | create > | | size | time | (ms/file) | files > | (MiB) | (KiB) | (ms) | real | kernel | (us/file) > ---+--------+--------+---------+----------+-----------+----------- > 1 | 298.7 | 3682 | 58.626 | 1.0228 | 0.6793 | 8.4916 > | sd=4.1 | | sd=0.47 | sd=0.058 | sd=0.0497 | sd=0.131 > 2 | 296.3 | 3682 | 58.915 | 1.0209 | 0.6752 | 8.5728 > | sd=3.9 | | sd=0.28 | sd=0.021 | sd=0.0244 | sd=0.156 > 3 | 295.7 | 3682 | 56.374 | 1.0160 | 0.6616 | 8.7467 > | sd=2.6 | | sd=0.44 | sd=0.008 | sd=0.0141 | sd=0.126 > 4 | 296.2 | 2585 | 51.434 | 1.0116 | 0.6699 | 8.7467 > | sd=4.1 | | sd=0.39 | sd=0.012 | sd=0.0115 | sd=0.126 > > [1] Create test_tty benchmark: > > mknod /dev/test_tty c 4 1 > time for i in `seq 1 10000`; do > mknod /dev/test_tty$i c 4 1 > done > > This benchmark should simulate the worst case scenario as many filename > transitions affect files created in the /dev directory. > > [2] https://github.com/mbitsnbites/osbench > > Reviewed-by: Ondrej Mosnacek <omosnace@xxxxxxxxxx> > Signed-off-by: Juraj Marcin <juraj@xxxxxxxxxxxxxxx> Reviewed-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
