Re: [PATCH v3 0/4] Improved seccomp logging

On 04/07/2017 05:46 PM, Kees Cook wrote: > Does the app-controlled bitmask apply to the filter, the process, the > process tree, or something else? e.g. systemd launches an app with a > filter, leaving the defaults alone, then later process installs a > filter and wants everything logged -- will things from the earlier > filter get logged? I think implementation preferences may decide many of these questions. As I see it, here are the options in order of my preference: A) Claim the MSB of the filter return value and make the app logging preference per-rule - If the bit is set, log the rule - Provides very fine-grained logging control at the "high cost" of the remaining free bit in the filter return bitmask - The bit can be ignored in the case of RET_KILL - Can be synced across all threads in the calling task with the SECCOMP_FILTER_FLAG_TSYNC filter flag B) Claim a few bits in the filter flags and make the app logging preference per-filter - Something like SECCOMP_FILTER_FLAG_LOG_TRAP, SECCOMP_FILTER_FLAG_LOG_ERRNO, and SECCOMP_FILTER_FLAG_LOG_TRACE - Logging for RET_KILL and RET_LOG can't be turned off - I'd prefer not to waste a bit for RET_ALLOW in this case so it simply won't be loggable - Works with the SECCOMP_FILTER_FLAG_TSYNC filter flag - Doesn't scale well if many new actions are added in the future C) A simplified version of 'B' where only a single mode bit is claimed to enable logging for all actions except RET_ALLOW - Something like SECCOMP_FILTER_FLAG_LOG_ACTIONS - Filters without this flag only log RET_KILL and RET_LOG - Scales much better than 'B' at the expense of less flexibility - Works with the SECCOMP_FILTER_FLAG_TSYNC filter flag D) Claim a bit in the filter mode and make the app logging preference per-process - This new SECCOMP_MODE_ENABLE_LOGGING mode would take a bitmask of actions that should be logged - Incurs a small per-task increase in memory footprint in the form of an additional member in 'struct seccomp' - Has odd behavior you described above where launchers may set the logging preference and then launched application may want something different I think 'A' is the cleanest design but I don't know if highly configurable logging is deserving of the MSB bit in the filter return. I'd like to hear your thoughts there. I _barely_ prefer 'B' over 'C'. They're essential equal in my use case. To be honest, I haven't completely wrapped my head around how 'D' would actually work in practice so I may be writing it off prematurely. Am I missing any more clever options that you can think of? Let me know what you think of the possibilities.