linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-security-module <linux-security-module@vger.kernel.org>,
	audit@vger.kernel.org, linux-audit@redhat.com,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: Re: [PATCH v2] TaskTracker : Simplified thread information tracker.
Date: Mon, 07 Aug 2023 14:54:24 -0400	[thread overview]
Message-ID: <2294714.ElGaqSPkdT@x2> (raw)
In-Reply-To: <ab7b4099-d238-e791-6dc2-25be5952798c@I-love.SAKURA.ne.jp>

On Monday, August 7, 2023 10:24:51 AM EDT Tetsuo Handa wrote:
> On 2023/08/07 7:01, Steve Grubb wrote:
> > This is where the problem begins. We like to have normalized audit
> > records. Meaning that a type of event defines the fields it contains. In
> > this case subject would be a process label. and there is already a
> > precedent for what fields belong in a syscall record.
> 
> What is the definition of "a process label"? SELinux / Smack / AppArmor are
> using security_secid_to_secctx() hook for providing string data for the
> subj= field. I don't think that they are restricting characters that can
> be included. Then, what is wrong with returning subset of ASCII printable
> characters from tt_secid_to_secctx() ?

Typically the label is used for access control decisions. But processes have 
other attributes such as a list of open files. I think adding this information 
will be useful - I'm not opposed to the idea. I am just thinking about how to 
present the information where it is more useful. 

<snip>

> > What I would suggest is to make a separate record: AUDIT_PROC_TREE that
> > describes process tree from the one killed up to the last known parent.
> > This way you can define your own format and SYSCALL can stay as everyone
> > expects it to look. In the EXECVE audit record, there is a precedent of
> > using agv[0]=xx argv[1]=xx argv[2]=yy  and so on. If you want to make
> > these generally parsable without special knowledge of the record format,
> > I'd suggest something like it.
> 
> Yes,
> https://lkml.kernel.org/r/201501202220.DJJ34834.OLJOHFMQOFtSVF@I-love.SAKU
> RA.ne.jp used AUDIT_PROCHISTORY instead of LSM hooks, but that thread died
> there.

I do not read that mail list. AUDIT_PROC_HIST or AUDIT_PROC_CHAIN or some 
thing like that would be the better way to go. If someone wanted to see if 
they have process history for a segfault, how would they do it with the 
proposed record?

ausearch --subject sshd

That just doesn't seem right. If you had a record dedicated to this 
information, then you can do:

ausearch -m PROC_HIST

and it would give you that information. And if you had the data split up 
like: p[0]=xx p[1]=xx p[2]=yy

Then  someone could do this to make a report specific to this:

import auparser as aup
au = aup.AuParser(aup.AUSOURCE_FILE, "audit.log")

au.search_add_expression("type r= PROC_HIST", aup.AUSEARCH_RULE_CLEAR)
au.search_set_stop(aup.AUSEARCH_STOP_RECORD)
while au.search_next_event():
    print("Call chain: ", end="")
    while True:
        print(au.interpret_field(), end = "")
        if au.next_field() == False:
            break
        print("->", end="")

au = None
sys.exit(0)

This would be more programmer friendly.

-Steve


--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit


  parent reply	other threads:[~2023-08-07 18:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-06 13:04 [PATCH v2] TaskTracker : Simplified thread information tracker Tetsuo Handa
2023-08-06 22:01 ` Steve Grubb
2023-08-07 14:24   ` Tetsuo Handa
2023-08-07 17:25     ` Casey Schaufler
2023-08-07 18:54     ` Steve Grubb [this message]
2023-08-08 10:25       ` Tetsuo Handa
2023-08-07 18:53 ` Paul Moore
2023-08-07 19:03   ` Steve Grubb
2023-08-07 20:13     ` Paul Moore
2023-08-08 10:07       ` Tetsuo Handa
2023-08-08 14:38         ` Paul Moore

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=2294714.ElGaqSPkdT@x2 \
    --to=sgrubb@redhat.com \
    --cc=audit@vger.kernel.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /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).