On Thu, Jul 27, 2023 at 12:43 PM Juraj Marcin <juraj@xxxxxxxxxxxxxxx> wrote: > > On 2023-07-17 14:44, Stephen Smalley wrote: > > > > I'd be curious to see what results you would get if you simply added > > the new feature (prefix/suffix matching) without moving the name-based > > transitions into the avtab. > > Here are the performance metrics of a prototype solution, where the > filename transition key is extended with match_type and match is found > by shortening the name from the end or the beginning if a full match is > not found. > > [2] Reference kernel (447a5688005e), Fedora policy (format v33) > [3] This patchset, Fedora policy (format v33) > [4] This patchset, Fedora policy without prefix/suffix rules (format v34) > [5] This patchset, Fedora policy with prefix rules (format v34) > > > Test | Mem | Binary | Policy | Create tty | osbench > | Usage | policy | load | | create > | | size | time | (ms/file) | files > | (MiB) | (MiB) | (ms) | real | kernel | (us/file) > ------+-------+--------+--------+--------+--------+----------- > [2] | 157 | 3.4 | 76 | 1.256 | 0.871 | 9.4492 > [3] | 156 | 3.4 | 77 | 1.208 | 0.869 | 9.6160 > [4] | 157 | 3.4 | 71 | 1.239 | 0.893 | 9.6297 > [5] | 156 | 2.4 | 71 | 1.211 | 0.838 | 9.8305 This looks more promising to me - little-to-no impact on existing users with old policy/userspace, reduced memory usage once fully transitioned. Still some degradation in runtime for osbench but not sure what the variance/stddev is for those numbers. > > Also wondering whether you considered the simpler approach of just > > augmenting the kernel to recognize and support use of wildcards at the > > beginning and/or end of the existing name field to signify a prefix or > > suffix match. That seems more amenable to extensions beyond just > > prefix or suffix match. > > I had not considered this approach in the beginning, but as I thought > about it, it did not seem as simple. > > For example, along with adding the wildcard character, we also need to > add the ability to escape it; otherwise, it would be a weird edge case > of an unsupported filename. Also, possibly to escape the escape > character itself. This adds more complexity to the solution. > > In addition to this, extending such solution to support wildcards > anywhere in the filename would also require reimplementing the filename > transitions structures or moving rules with wildcards away from current > filename transitions. Currently, the filename is part of the hashtab key > and prefix/suffix could work by checking all prefixes and suffixes of a > filename, which there are not that many. However, with a wildcard at any > position, this is not feasible. Fair enough. That said, I do wonder if users will immediately start asking for wildcards at any position, then file globbing or regexes, etc, and would like to allow for future extensibility in a less disruptive manner.
