From: L A Walsh <lkml@tlinx.org>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
Subject: Re: Identifying thread/process termination
Date: Tue, 17 Nov 2020 07:22:24 -0800 [thread overview]
Message-ID: <5FB3EAB0.3040503@tlinx.org> (raw)
In-Reply-To: <CAHC9VhTh6wk7O+dsN3zeguR83v8G=ykosR95smfy5WmML+XXfA@mail.gmail.com>
On 2020/11/16 05:43, Paul Moore wrote:
> The most important thing to keep in mind is that all of the threads
> inside a process share the same memory space. It is the lack of a
> strong, enforceable boundary between threads which makes it difficult,
> if not impossible, to view threads as individual entities from a
> security perspective.
---
Depends on how much your security policy relies on recognizing
abnormal behavior. If a program splits function across well defined
areas by a named thread, one may develop a baseline of "normal"
functionality associated with given threads. Determining that
a thread is operating outside it's normal range can allow for a
earlier detection and better monitoring of "safe" and/or secure
operation.
How programs operate, especially in regards to what work is
normal for a given thread can only be done with thread level
monitoring. While given threads _can_ access global-user memory,
that involves how they are coded or programmed to run. That, in
turn, can be used to help define boundaries and integrity levels
of various processes in a system.
For example, even though a logging thread might gather data
from other threads, knowing that it can only write to output
to specific configured destinations would allow swift detection
of aberrations.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-11-17 17:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 19:07 Identifying thread/process termination Natan Yellin
2020-10-06 20:20 ` Steve Grubb
2020-10-08 1:27 ` Paul Moore
2020-10-08 7:59 ` Natan Yellin
2020-10-09 1:12 ` Paul Moore
2020-10-08 12:49 ` Richard Guy Briggs
2020-10-08 15:33 ` Lenny Bruzenak
2020-11-16 6:41 ` L. A. Walsh
2020-11-16 13:43 ` Paul Moore
2020-11-17 15:22 ` L A Walsh [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-11-20 19:43 L. A. Walsh
2020-11-24 15:43 ` Lenny Bruzenak
2020-11-20 19:45 L. A. Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5FB3EAB0.3040503@tlinx.org \
--to=lkml@tlinx.org \
--cc=linux-audit@redhat.com \
--cc=paul@paul-moore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.