Hi,
On Sun, Apr 25, 2021 at 08:01:55AM -0400, Jeffrey Walton wrote:
> On Sun, Apr 25, 2021 at 7:09 AM John Wood wrote:
> >
> > I'm working in a LSM to detect and mitigate fork brute force attacks
> > against vulnerable userspace applications. Now, to fine tuning t
_dev_if" member of the sock struct but its
value is always 0 for internal and external connections (at least in my
tests).
How can I detect that an external connection (using a net device) is
accepted and avoid internal network communication?
userspace monitor would
> have more options (though a slightly higher risk of race conditions).
>
Thanks for the ideas. I need some time to send a formal proposal that
works properly. I would like to get feedback at that moment. I think it
would be better to discuss about the real patch.
A
cache (which wouldn't actually be a cache, but a complete database)
> might actually work.
Thanks. I will keep it in mind.
>
> -Andi
Regards,
John Wood
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
any caches of limited
> size can be always thrashed by a purposeful attacker. I suppose the
> only thing that would work is to actually write something to the
> executable itself on disk, but of course that doesn't always work either.
I'm also working on this. In the next ver
Hi Valdis,
On Tue, Apr 06, 2021 at 07:55:36PM -0400, Valdis Klētnieks wrote:
> On Mon, 05 Apr 2021 09:31:47 +0200, John Wood said:
>
> > > And how does the kernel know that it's notifying a "real" supervisor
> > > process,
> > > and not a pro
Hi,
On Sun, Apr 04, 2021 at 05:10:25PM -0400, Valdis Klētnieks wrote:
> On Sun, 04 Apr 2021 11:48:37 +0200, John Wood said:
>
> > that exec and the child crashes is mitigated. The only drawback here, as
> > point Andi, is that a supervisor respawns some process killed. To avoid
Hi,
On Sat, Apr 03, 2021 at 05:34:01PM -0400, Valdis Klētnieks wrote:
> On Sat, 03 Apr 2021 09:02:26 +0200, John Wood said:
>
> > Currently, the scenario you propose is fully mitigated :). And notifying to
> > userspace that all the tasks has been killed by "Brute" n
Hi,
On Fri, Apr 02, 2021 at 11:50:18PM -0400, Valdis Klētnieks wrote:
> On Fri, 02 Apr 2021 14:49:32 +0200, John Wood said:
>
> > the attack can be started again. So, he suggested that notifying to
> > userspace
> > (via wait*() functions) that a child task has b
Hi,
On Tue, Mar 30, 2021 at 02:40:38PM -0400, Valdis Klētnieks wrote:
> On Tue, 30 Mar 2021 19:34:59 +0200, John Wood said:
>
> > The question is: How can I notify to wait* functions that the task has
> > been killed by the "Brute" LSM.
>
> What wait* functions
ll of this is that using the waitid function from
userspace (or waitpid function) we can know that a child task has been killed
by the "Brute" LSM or not. I try to inform to userspace that a task has been
killed due to the "Brute" mit
On Sun, Dec 20, 2020 at 03:06:52PM -0500, Valdis Klētnieks wrote:
> On Sun, 20 Dec 2020 12:47:08 +0100, John Wood said:
>
> > disable interrupts. Then, the task_free hook was call from an IRQ context
> > and tried to acquire the same lock in a write state.
>
> OK, I'l
On Sat, Dec 19, 2020 at 12:46:37PM +0100, John Wood wrote:
> Hi,
>
> I'm working in a new LSM to detect and mitigate any fork brute force
> attack against vulnerable userspace processes. I'm testing the detection
> method but I have found some problems that I think are r
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
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
).
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
the code used. Any help that points me to the
right direction would be greatly appreciated.
Thanks a lot.
John Wood (4):
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 brute for
On Tue, 08 Dec 2020 09:42:59 -0500, Valdis Klētnieks wrote:
> On Tue, 08 Dec 2020 11:35:57 +0100, John Wood said:
> > I think the stats pointer present in the task_struct's security blob
> > needs to be protected against concurrency for the following reasons.
> >
> &
keesc...@chromium.org/
v2
https://lore.kernel.org/kernel-hardening/20201025134540.3770-1-john.w...@gmx.com/
Thanks in advance.
John Wood (2):
security/brute: Brute LSM
security/brute.c: Protect the stats pointer
security/brute/brute.c | 381 +
1 f
s is managed in the task_fatal_signal hook (defined in a previous
patch not shown in this RFC).
Signed-off-by: John Wood
---
security/brute/brute.c | 358 +
1 file changed, 358 insertions(+)
create mode 100644 security/brute/brute.c
diff --git a/security/
rite to the stats structure to compute the crash
period.
Any constructive comments are welcome. I would like to know your
opinions about my locking system but remember that I'm a newbie :)
Signed-off-by: John Wood
---
security/brute/brute.c | 35 +--
1
Hi,
On Fri, Oct 02, 2020 at 06:59:22PM +0200, John Wood wrote:
>
> static void brute_share_stats(struct brute_stats **src,
> struct brute_stats **dst)
> {
> spin_lock(&(*src)->lock);
> refcount_inc(&(*src)->refc);
>
Hi,
On Thu, Oct 01, 2020 at 08:29:58PM -0400, Valdis Klētnieks wrote:
> On Thu, 01 Oct 2020 19:49:02 +0200, John Wood said:
>
> > Idea: The purpose of my LSM is to detect and mitigate a fork brute force
> > attack. To do so, I need a hierarchy of fork processes. In other words,
On Wed, Sep 30, 2020 at 07:59:47AM -0400, Valdis Klētnieks wrote:
> On Fri, 25 Sep 2020 18:11:42 +0200, John Wood said:
>
> > There are more examples but are similars to the ones showed. So my question
> > is how to read the "real_parent" field correctly. If I can
correct way.
Any help that points me to the right direction will be greatly apreciated.
Some rules to know when and why use a method or another are welcome.
Thanks in advance. Regards,
John Wood
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
25 matches
Mail list logo
