On Sun, Mar 21, 2021 at 12:50:47PM -0600, Jonathan Corbet wrote:
> John Wood writes:
>
> > Add some info detailing what is the Brute LSM, its motivation, weak
> > points of existing implementations, proposed solutions, enabling,
> > disabling and self-tests.
> >
Hi,
On Sun, Mar 21, 2021 at 11:45:59AM -0700, Kees Cook wrote:
> On Sun, Mar 21, 2021 at 04:01:18PM +0100, John Wood wrote:
> > On Wed, Mar 17, 2021 at 07:57:10PM -0700, Kees Cook wrote:
> > > On Sun, Mar 07, 2021 at 12:30:26PM +0100, John Wood wrote:
> > Sorry, but I try
On Wed, Mar 17, 2021 at 07:57:10PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:26PM +0100, John Wood wrote:
> > +static u64 brute_update_crash_period(struct brute_stats *stats, u64 now)
> > +{
> > + u64 current_period;
> > + u64 last_crash_timestamp;
>
On Wed, Mar 17, 2021 at 09:10:05PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:30PM +0100, John Wood wrote:
> > +These statistics are hold by the brute_stats struct.
> > +
> > +struct brute_cred {
> > + kuid_t uid;
> > + kgid_t gid;
> &g
On Wed, Mar 17, 2021 at 09:08:17PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:29PM +0100, John Wood wrote:
> > +
> > +count_fork_matches()
> > +{
> > + dmesg | grep "brute: Fork brute force attack detected" | wc -l
>
> This may be unsta
On Wed, Mar 17, 2021 at 09:04:15PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:28PM +0100, John Wood wrote:
> > +/**
> > + * brute_kill_offending_tasks() - Kill the offending tasks.
> > + * @attack_type: Brute force attack type.
> > + * @stats: Statistical
On Wed, Mar 17, 2021 at 09:00:51PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:27PM +0100, John Wood wrote:
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> > +#include
> &g
On Wed, Mar 17, 2021 at 07:57:10PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:26PM +0100, John Wood wrote:
> > @@ -74,7 +84,7 @@ static struct brute_stats *brute_new_stats(void)
> > {
> > struct brute_stats *stats;
> >
> > - stats =
Hi,
First of all thanks for the review. More info and questions inline.
On Wed, Mar 17, 2021 at 07:00:56PM -0700, Kees Cook wrote:
> On Sun, Mar 07, 2021 at 12:30:25PM +0100, John Wood wrote:
> >
> > config LSM
> > string "Ordered list of enabled LSMs"
>
emons.
>
I will work on your solution regarding respawned daemons (use wait*() to inform
userspace that the offending processes killed by the mitigation exited due to
this mitigation -> then the supervisor can adopt their own policy).
>
> -Andi
>
Thank you very much,
John Wood
userspace that every process killed by the mitigation
has exited due to a brute force attack mitigation. So, each supervisor can
adopt their own policy regarding respawned daemons.
I will work in that direction for the next version.
Thanks a lot for your time, proposals, guidance and solutions.
John Wood
Hi,
On Thu, Mar 11, 2021 at 09:32:47PM +0100, peter enderborg wrote:
> On 2/27/21 4:30 PM, John Wood wrote:
> > In order to mitigate a brute force attack all the offending tasks involved
> > in the attack must be killed. In other words, it is necessary to kill all
> > the
Hi,
On Tue, Mar 09, 2021 at 07:40:54PM +0100, John Wood wrote:
> On Sun, Mar 07, 2021 at 02:49:27PM -0800, Andi Kleen wrote:
>
> > So I think it needs more work on the user space side for most usages.
>
> Anyway, in the case that the supervisor is init then the system will panic
Hi,
On Sun, Mar 07, 2021 at 02:49:27PM -0800, Andi Kleen wrote:
> On Sun, Mar 07, 2021 at 07:05:41PM +0100, John Wood wrote:
> > On Sun, Mar 07, 2021 at 09:25:40AM -0800, Andi Kleen wrote:
> > > > processes created from it will be killed. If the systemd restart the
> >
t might be ok depending on the use case,
> but people certainly need to be aware of it.
>
> It's probably not something you want to have enabled by default ever.
>
> -Andi
>
Thanks,
John Wood
ssary the customization of this feature by the user. I aggree
with that.
>
> -Andi
I have sent a v6 version with the documentation improved.
Thanks for your comments,
John Wood
In order to maintain the code for the Brute LSM add a new entry to the
maintainers list.
Signed-off-by: John Wood
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..0b88b7a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Add some info detailing what is the Brute LSM, its motivation, weak
points of existing implementations, proposed solutions, enabling,
disabling and self-tests.
Signed-off-by: John Wood
---
Documentation/admin-guide/LSM/Brute.rst | 278
Documentation/admin-guide/LSM
boundariy already commented doesn't trigger the
detection and mitigation stage.
All the fork brute force attacks are carried out via the "exec" app to
avoid the triggering of the "brute" LSM over the shell script running
the tests.
Signed-off-by: John Wood
---
tools/t
ompute the application crash period in this case.
Signed-off-by: John Wood
---
security/brute/brute.c | 141 ++---
1 file changed, 132 insertions(+), 9 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index 38e5e050964a..36a3286a0
glibc for stack canary, malloc, etc failures, which may
indicate that a mitigation has been triggered.
Signed-off-by: John Wood
---
security/brute/brute.c | 293 +++--
1 file changed, 280 insertions(+), 13 deletions(-)
diff --git a/security/brute/brute.c b
he maximum number of faults per fork
hierarchy is reached and a fast brute force attack that is detected if
the application crash period falls below a certain threshold.
Also, this patch adds locking to protect the statistics pointer hold by
every process.
Signed-off-by: John Wood
---
security/bru
s. These hooks are "task_alloc" to do
the fork management, "bprm_committing_creds" to do the execve management
and "task_free" to release the resources.
Also, add to the task_struct's security blob the pointer to the
statistical data. This way, all the task
).
Signed-off-by: John Wood
---
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4
include/linux/security.h | 4
kernel/signal.c | 1 +
security/security.c | 5 +
5 files changed, 15 insertions(+)
diff --git a/include/linux/lsm_hoo
-
- Fix some typos (Randy Dunlap).
Changelog v5 -> v6
--
- Fix a reported deadlock (kernel test robot).
- Add high level details to the documentation (Andi Kleen).
Any constructive comments are welcome.
Thanks.
John Wood (8):
security: Add LSM hook at the point where a task gets a f
stical data")
> url:
> https://github.com/0day-ci/linux/commits/John-Wood/Fork-brute-force-attack-mitigation/20210228-022911
> base: https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git
> next
>
> in testcase: trinity
> version: trinity-static-i386
On Sun, Feb 28, 2021 at 10:56:45AM -0800, Andi Kleen wrote:
> John Wood writes:
> > +
> > +To detect a brute force attack it is necessary that the statistics shared
> > by all
> > +the fork hierarchy processes be updated in every fatal crash and the most
> >
Sorry. Drop this patch serie.
Thanks,
John Wood
On Sat, Feb 27, 2021 at 04:30:05PM +0100, John Wood wrote:
>
> This patch serie is a task of the KSPP [1] and can also be accessed from my
> github tree [2] in the "brute_v4" branch.
Sorry. The correct branch is "brute_v5".
Apologies.
John Wood
>
> [1] http
In order to maintain the code for the Brute LSM add a new entry to the
maintainers list.
Signed-off-by: John Wood
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..0b88b7a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Add some info detailing what is the Brute LSM, its motivation, weak
points of existing implementations, proposed solutions, enabling,
disabling and self-tests.
Signed-off-by: John Wood
---
Documentation/admin-guide/LSM/Brute.rst | 224
Documentation/admin-guide/LSM
boundariy already commented doesn't trigger the
detection and mitigation stage.
All the fork brute force attacks are carried out via the "exec" app to
avoid the triggering of the "brute" LSM over the shell script running
the tests.
Signed-off-by: John Wood
---
tools/t
ompute the application crash period in this case.
Signed-off-by: John Wood
---
security/brute/brute.c | 141 ++---
1 file changed, 132 insertions(+), 9 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index 0a99cd4c3303..48b07d923
glibc for stack canary, malloc, etc failures, which may
indicate that a mitigation has been triggered.
Signed-off-by: John Wood
---
security/brute/brute.c | 293 +++--
1 file changed, 280 insertions(+), 13 deletions(-)
diff --git a/security/brute/brute.c b
he maximum number of faults per fork
hierarchy is reached and a fast brute force attack that is detected if
the application crash period falls below a certain threshold.
Also, this patch adds locking to protect the statistics pointer hold by
every process.
Signed-off-by: John Wood
---
security/bru
s. These hooks are "task_alloc" to do
the fork management, "bprm_committing_creds" to do the execve management
and "task_free" to release the resources.
Also, add to the task_struct's security blob the pointer to the
statistical data. This way, all the task
).
Signed-off-by: John Wood
---
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4
include/linux/security.h | 4
kernel/signal.c | 1 +
security/security.c | 5 +
5 files changed, 15 insertions(+)
diff --git a/include/linux/lsm_hoo
lidate the expectations (Kees Cook).
Changelog v3 -> v4
--
- Fix all the warnings shown by the tool "scripts/kernel-doc" (Randy
Dunlap).
Changelog v4 -> v5
--
- Fix some typos (Randy Dunlap).
Any constructive comments are welcome.
Thanks.
John Wood (8):
securit
ings shown by the tool "scripts/kernel-doc" (Randy
Dunlap).
Any constructive comments are welcome.
Thanks.
John Wood (8):
security: Add LSM hook at the point where a task gets a fatal signal
security/brute: Define a LSM and manage statistical data
securtiy/brute: Detect a
Hi,
On Sun, Feb 21, 2021 at 06:30:10PM -0800, Randy Dunlap wrote:
> Hi,
>
> one spello in 2 locations:
>
> On 2/21/21 7:49 AM, John Wood wrote:
> [...]
> > these statistics dissapear when the involved tasks finished. In this
>
>disappear
> [
erstand function prototype: 'const
> unsigned char BRUTE_MIN_FAULTS = 5; '
> ../src/megatest.c:1249: warning: cannot understand function prototype: 'const
> u64 BRUTE_CRASH_PERIOD_THRESHOLD = 3; '
>
>
> On 2/21/21 7:49 AM, John Wood wrote:
> >
&g
Hi,
On Sun, Feb 21, 2021 at 06:25:51PM -0800, Randy Dunlap wrote:
> Hi--
>
> On 2/21/21 7:49 AM, John Wood wrote:
> >
> > +/**
> > + * print_fork_attack_running() - Warn about a fork brute force attack.
> > + */
> > +static inline void print_fork_attack_run
In order to maintain the code for the Brute LSM add a new entry to the
maintainers list.
Signed-off-by: John Wood
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index bfc1b86e3e73..a88327198474 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Add some info detailing what is the Brute LSM, its motivation, weak
points of existing implementations, proposed solutions, enabling,
disabling and self-tests.
Signed-off-by: John Wood
---
Documentation/admin-guide/LSM/Brute.rst | 224
Documentation/admin-guide/LSM
boundariy already commented doesn't trigger the
detection and mitigation stage.
All the fork brute force attacks are carried out via the "exec" app to
avoid the triggering of the "brute" LSM over the shell script running
the tests.
Signed-off-by: John Wood
---
tools/t
ompute the application crash period in this case.
Signed-off-by: John Wood
---
security/brute/brute.c | 141 ++---
1 file changed, 132 insertions(+), 9 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index 8d03ea0ecac5..581aba291
glibc for stack canary, malloc, etc failures, which may
indicate that a mitigation has been triggered.
Signed-off-by: John Wood
---
security/brute/brute.c | 293 +++--
1 file changed, 280 insertions(+), 13 deletions(-)
diff --git a/security/brute/brute.c b
he maximum number of faults per fork
hierarchy is reached and a fast brute force attack that is detected if
the application crash period falls below a certain threshold.
Also, this patch adds locking to protect the statistics pointer hold by
every process.
Signed-off-by: John Wood
---
security/bru
s. These hooks are "task_alloc" to do
the fork management, "bprm_committing_creds" to do the execve management
and "task_free" to release the resources.
Also, add to the task_struct's security blob the pointer to the
statistical data. This way, all the task
).
Signed-off-by: John Wood
---
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4
include/linux/security.h | 4
kernel/signal.c | 1 +
security/security.c | 5 +
5 files changed, 15 insertions(+)
diff --git a/include/linux/lsm_hoo
e the documentation (Kees Cook).
- Fix some typos in the documentation (Randy Dunlap).
- Add self-test to validate the expectations (Kees Cook).
John Wood (8):
security: Add LSM hook at the point where a task gets a fatal signal
security/brute: Define a LSM and manage statistical data
securtiy/b
On Tue, Nov 10, 2020 at 04:10:49PM -0800, Kees Cook wrote:
> On Sun, Oct 25, 2020 at 02:45:32PM +0100, John Wood wrote:
> > Attacks against vulnerable userspace applications with the purpose to break
> > ASLR or bypass canaries traditionaly use some level of brute force with the
will also be detected and
mitigated.
What do you think?
>
> thanks for the documentation.
> --
> ~Randy
>
Thanks,
John Wood
Hi,
Has anyone had time to review this patch serie? Any comments on this?
Regards.
On Sun, Oct 25, 2020 at 02:45:32PM +0100, John Wood wrote:
> Attacks against vulnerable userspace applications with the purpose to break
> ASLR or bypass canaries traditionaly use some level of brute forc
In order to maintain the code for the Brute LSM add a new entry to the
maintainers list.
Signed-off-by: John Wood
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 867157311dc8..3d3b34f87913 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Add some info detailing what is the Brute LSM, its motivation, weak
points of existing implementations, proposed solutions, enabling,
disabling and fine tuning.
Signed-off-by: John Wood
---
Documentation/admin-guide/LSM/Brute.rst | 118
Documentation/admin-guide/LSM
crashes timestamps list not
empty. To disable the detection use the already created brute_disable()
function.
Signed-off-by: John Wood
---
include/brute/brute.h | 16 +
include/uapi/linux/prctl.h | 4 +++
kernel/sys.c | 8 +
security/brute/brute.c | 71
avoid to compute the application crash period if the size of this
list is zero.
Signed-off-by: John Wood
---
security/brute/brute.c | 144 ++---
1 file changed, 135 insertions(+), 9 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index
that falls under the defined
threshold shows that the application is crashing quickly and there is a
clear signal that an attack is happening.
Signed-off-by: John Wood
---
security/brute/brute.c | 130 +
1 file changed, 130 insertions(+)
diff --git a/secu
ility adjusting the
application crash period threshold and the size of the last crashes
timestamps list.
Signed-off-by: John Wood
---
security/brute/brute.c | 83 ++
1 file changed, 83 insertions(+)
diff --git a/security/brute/brute.c b/security/brute/br
uot;task_alloc" to do
the fork management, "bprm_committing_creds" for do the execve
management and "task_free" to release the resources.
Also, add to the task_struct's security blob the pointer to the
statistical data. This way, all the tasks will have access to this
i
).
Signed-off-by: John Wood
---
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4
include/linux/security.h | 4
kernel/signal.c | 1 +
security/security.c | 5 +
5 files changed, 15 insertions(+)
diff --git a/include/linux/lsm_hoo
void data races (Jann Horn).
- Add a new LSM hook to get the fatal signal of a task (Jann Horn, Kees
Cook).
- Add the last crashes timestamps list to avoid false positives in the
attack detection (Jann Horn).
- Use "period" instead of "rate" (Jann Horn).
- Other minor changes s
anyone to attach to. Not just tracing.
> >
> And there's also trace_sched_process_fork() and
> trace_sched_process_exit().
Since this feature requires a pointer to the statistical data in the
task_struct structure, and the LSM allows this using the security blobs,
I think that the best for now is convert all the code to an LSM. Anyway,
thanks for the suggestion.
> -- Steve
Thanks,
John Wood
On Fri, Sep 18, 2020 at 02:35:12PM -0700, Kees Cook wrote:
> On Fri, Sep 18, 2020 at 06:02:16PM +0200, John Wood wrote:
> > On Thu, Sep 10, 2020 at 04:56:19PM -0700, Kees Cook wrote:
> > > On Thu, Sep 10, 2020 at 01:21:07PM -0700, Kees Cook wrote:
> > > > +
BUILD_MODNAME ": " fmt
Understood.
> > +
> > + killed += 1;
> > + if (killed >= to_kill)
> > + break;
> > + }
> > +
> > + rcu_read_unlock();
>
> Can't newly created processes escape this RCU read lock? I think this
> need alternate locking, or something in the task_alloc hook that will
> block any new process from being created within the stats group.
I will work on this for the next version. Thanks.
> > + return 0;
> > +}
>
> --
> Kees Cook
Thanks
John Wood
On Thu, Sep 17, 2020 at 03:05:18PM -0700, Kees Cook wrote:
> On Thu, Sep 17, 2020 at 08:40:06PM +0200, John Wood wrote:
> > > To jump on the bikeshed: how about just calling this
> > > FORK_BRUTE_FORCE_DETECTION or FORK_BRUTE, and the directory could be
> > > &quo
Hi,
On Thu, Sep 10, 2020 at 04:18:08PM -0700, Kees Cook wrote:
> On Thu, Sep 10, 2020 at 01:21:02PM -0700, Kees Cook wrote:
> > From: John Wood
> >
> > Add a menu entry under "Security options" to enable the "Fork brute
> > force attack mitigation&
On Thu, Sep 10, 2020 at 11:21:58PM +0200, Jann Horn wrote:
> On Thu, Sep 10, 2020 at 10:21 PM Kees Cook wrote:
> > From: John Wood
> >
> > Add a menu entry under "Security options" to enable the "Fork brute
> > force attack mitigation" feature.
&
On Mon, Sep 14, 2020 at 09:42:37PM +0200, Jann Horn wrote:
> On Sun, Sep 13, 2020 at 7:55 PM John Wood wrote:
> > On Thu, Sep 10, 2020 at 11:10:38PM +0200, Jann Horn wrote:
> > > > + delta_jiffies = get_jiffies_64() - stats->jiffies;
> > > > +
Hi,
On Mon, Sep 14, 2020 at 09:39:10PM +0200, Jann Horn wrote:
> On Sun, Sep 13, 2020 at 6:56 PM John Wood wrote:
> > On Fri, Sep 11, 2020 at 02:01:56AM +0200, Jann Horn wrote:
> > > On Fri, Sep 11, 2020 at 1:49 AM Kees Cook wrote:
> > > > On Thu, Sep 10, 2020
And so, the attack detection only will be triggered if the
application crashes quickly but after a number of crashes.
What do you think?
>
> (By the way, it kind of annoys me that you call it the "rate" when
> it's actually the inverse of the rate. "Period" might be more
> appropriate?)
Yes, "period" it's more appropiate. Thanks for the clarification.
> > + if (crashing_rate < (u64)sysctl_crashing_rate_threshold)
> > + pr_warn("fbfam: Fork brute force attack detected\n");
> > +
> > + return 0;
> > +}
> > +
> > --
> > 2.25.1
> >
Regards,
John Wood
7;s not really semantically about core dumping, maybe it should
> be named task_fatal_signal or something like that.
If I understand correctly you propose to add a new LSM hook without return
value and place it here:
diff --git a/kernel/signal.c b/kernel/signal.c
index a38b3edc6851..074492d23e98 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2751,6 +2751,8 @@ bool get_signal(struct ksignal *ksig)
do_coredump(&ksig->info);
}
+ // Add the new LSM hook here
+
/*
* Death signals, no core dump.
*/
Thanks,
John Wood
r: GPL-2.0
> > +#include
> > +
> > +extern unsigned long sysctl_crashing_rate_threshold;
> > +static unsigned long ulong_one = 1;
> > +static unsigned long ulong_max = ULONG_MAX;
> > +
> > +struct ctl_table fbfam_sysctls[] = {
> > + {
> > + .procname = "crashing_rate_threshold",
> > + .data = &sysctl_crashing_rate_threshold,
> > + .maxlen = sizeof(sysctl_crashing_rate_threshold),
> > + .mode = 0644,
> > + .proc_handler = proc_doulongvec_minmax,
> > + .extra1 = &ulong_one,
> > + .extra2 = &ulong_max,
> > + },
> > + { }
> > +};
>
> I wouldn't bother splitting this into a separate file. (Just leave it in
> fbfam.c)
>
> --
> Kees Cook
Thanks,
John Wood
Hi,
On Sat, Sep 12, 2020 at 10:48:39PM +0200, Ondrej Mosnacek wrote:
> On Sat, Sep 12, 2020 at 4:51 PM Mel Gorman wrote:
> > On Sat, Sep 12, 2020 at 11:36:52AM +0200, John Wood wrote:
> > > On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> > > > On S
On Sat, Sep 12, 2020 at 12:55:03AM -0700, Kees Cook wrote:
> On Fri, Sep 11, 2020 at 04:48:06PM +0200, John Wood wrote:
> > My original patch serie is composed of 9 patches, so the 3 lasts are lost.
> > Kees: Have you removed them for some reason? Can you send them for review?
&
On Sat, Sep 12, 2020 at 12:56:18AM -0700, Kees Cook wrote:
> On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> > On Thu, 10 Sep 2020, Kees Cook wrote:
> >
> > > [kees: re-sending this series on behalf of John Wood
> > > also visible at https
Hi,
On Thu, Sep 10, 2020 at 04:58:29PM -0700, Kees Cook wrote:
> On Thu, Sep 10, 2020 at 01:21:01PM -0700, Kees Cook wrote:
> > From: John Wood
> >
> > The goal of this patch serie is to detect and mitigate a fork brute force
> > attack.
>
> Thanks for this RFC
() to not compute the crashing rate when the jiffies
stored in the statistical data are set to zero.
Signed-off-by: John Wood
---
security/fbfam/fbfam.c | 76 +++---
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/security/fbfam/fbfam.c b/security
that an attack is happening.
Since the crashing rate is computed in milliseconds per fault, if this
rate goes under a certain threshold a warning is triggered.
Signed-off-by: John Wood
---
fs/coredump.c | 2 ++
include/fbfam/fbfam.h | 2 ++
security/fbfam/fbfam.c | 39
x27;s sensibility adjusting the
milliseconds per fault. So, if the application's crashing rate falls
under this threshold an attack will be detected. So, the higher this
value, the faster an attack will be detected.
Signed-off-by: John Wood
---
include/fbfam/fbfam.h | 4
kernel/sysctl.c
Use the previous defined api to manage statistics calling it accordingly
when a task forks, calls execve or exits.
Signed-off-by: John Wood
---
fs/exec.c | 2 ++
kernel/exit.c | 2 ++
kernel/fork.c | 4
3 files changed, 8 insertions(+)
diff --git a/fs/exec.c b/fs/exec.c
index
n all the previous information add the api to manage all the
commented cases.
Also, add to the struct task_struct a new field to point to the
statitistical data related to an attack. This way, all the tasks will
have access to this information.
Signed-off-by: John Wood
---
include/fbfam/fb
Add a menu entry under "Security options" to enable the "Fork brute
force attack mitigation" feature.
Signed-off-by: John Wood
---
security/Kconfig | 1 +
security/fbfam/Kconfig | 10 ++
2 files changed, 11 insertions(+)
create mode 100644 security/fbfam/K
Hi. I have problems with my email account to send the patch serie [1] to
all the recipients. My account blocks if I send an email to a big amount of
recipients.
Please don't reply to this message.
Thanks
[1]
https://lore.kernel.org/kernel-hardening/20200906121544.4204-1-john.w...@gmx.com/
warning: objtool: native_play_dead()+0x122:
unreachable instruction
net/core/skbuff.o: warning: objtool: skb_push.cold()+0x14: unreachable
instruction
John Wood (9):
security/fbfam: Add a Kconfig to enable the fbfam feature
security/fbfam: Add the api to manage statistics
security/fbfam
86 matches
Mail list logo