linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: "L. A. Walsh" <linux-audit@tlinx.org>
To: linux-audit@redhat.com
Subject: Identifying thread/process termination
Date: Fri, 20 Nov 2020 11:45:01 -0800	[thread overview]
Message-ID: <5FB81CBD.7040500@tlinx.org> (raw)

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


             reply	other threads:[~2020-11-20 19:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-20 19:45 L. A. Walsh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-11-20 19:43 Identifying thread/process termination L. A. Walsh
2020-11-24 15:43 ` Lenny Bruzenak
2020-10-05 19:07 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

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=5FB81CBD.7040500@tlinx.org \
    --to=linux-audit@tlinx.org \
    --cc=linux-audit@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).