| Message ID | 20220908220222.267255-1-nathanl@linux.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | lockdown: ratelimit denial messages | expand |
On Thu, Sep 8, 2022 at 6:02 PM Nathan Lynch <nathanl@linux.ibm.com> wrote: > > User space can flood the log with lockdown denial messages: > > [ 662.555584] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > [ 662.563237] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > [ 662.571134] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > [ 662.578668] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > [ 662.586021] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > [ 662.593398] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > Ratelimiting these shouldn't meaningfully degrade the quality of the > information logged. > > Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> > --- > security/lockdown/lockdown.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This seems reasonable. While the last visible lockdown message to the console might be incorrect/old, I think it would give the user a good indication that lockdown is being hit and hopefully preserve the start of the denial storm. It is also worth noting that this does introduce a spinlock to this code path, but since it is only an issue on error I doubt it will have any significant impact. I'll leave this until next week to give people a chance to comment/object, but if there are no further comments I'll plan on merging this into lsm/next. > diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c > index 87cbdc64d272..a79b985e917e 100644 > --- a/security/lockdown/lockdown.c > +++ b/security/lockdown/lockdown.c > @@ -63,7 +63,7 @@ static int lockdown_is_locked_down(enum lockdown_reason what) > > if (kernel_locked_down >= what) { > if (lockdown_reasons[what]) > - pr_notice("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n", > + pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n", > current->comm, lockdown_reasons[what]); > return -EPERM; > } > -- > 2.37.1
On Fri, Sep 9, 2022 at 10:05 AM Paul Moore <paul@paul-moore.com> wrote: > On Thu, Sep 8, 2022 at 6:02 PM Nathan Lynch <nathanl@linux.ibm.com> wrote: > > > > User space can flood the log with lockdown denial messages: > > > > [ 662.555584] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > [ 662.563237] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > [ 662.571134] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > [ 662.578668] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > [ 662.586021] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > [ 662.593398] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 > > > > Ratelimiting these shouldn't meaningfully degrade the quality of the > > information logged. > > > > Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> > > --- > > security/lockdown/lockdown.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > This seems reasonable. While the last visible lockdown message to the > console might be incorrect/old, I think it would give the user a good > indication that lockdown is being hit and hopefully preserve the start > of the denial storm. It is also worth noting that this does introduce > a spinlock to this code path, but since it is only an issue on error I > doubt it will have any significant impact. > > I'll leave this until next week to give people a chance to > comment/object, but if there are no further comments I'll plan on > merging this into lsm/next. Now merged into lsm/next, thanks!
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c index 87cbdc64d272..a79b985e917e 100644 --- a/security/lockdown/lockdown.c +++ b/security/lockdown/lockdown.c @@ -63,7 +63,7 @@ static int lockdown_is_locked_down(enum lockdown_reason what) if (kernel_locked_down >= what) { if (lockdown_reasons[what]) - pr_notice("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n", + pr_notice_ratelimited("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n", current->comm, lockdown_reasons[what]); return -EPERM; }
User space can flood the log with lockdown denial messages: [ 662.555584] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.563237] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.571134] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.578668] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.586021] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 [ 662.593398] Lockdown: bash: debugfs access is restricted; see man kernel_lockdown.7 Ratelimiting these shouldn't meaningfully degrade the quality of the information logged. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> --- security/lockdown/lockdown.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)