All of lore.kernel.org
 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



WARNING: multiple messages have this Message-ID (diff)
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:55 UTC|newest]

Thread overview: 22+ 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 13:04 ` Tetsuo Handa
2023-08-06 22:01 ` Steve Grubb
2023-08-06 22:01   ` Steve Grubb
2023-08-07 14:24   ` Tetsuo Handa
2023-08-07 14:24     ` Tetsuo Handa
2023-08-07 17:25     ` Casey Schaufler
2023-08-07 17:25       ` Casey Schaufler
2023-08-07 18:54     ` Steve Grubb [this message]
2023-08-07 18:54       ` Steve Grubb
2023-08-08 10:25       ` Tetsuo Handa
2023-08-08 10:25         ` Tetsuo Handa
2023-08-07 18:53 ` Paul Moore
2023-08-07 18:53   ` Paul Moore
2023-08-07 19:03   ` Steve Grubb
2023-08-07 19:03     ` Steve Grubb
2023-08-07 20:13     ` Paul Moore
2023-08-07 20:13       ` Paul Moore
2023-08-08 10:07       ` Tetsuo Handa
2023-08-08 10:07         ` Tetsuo Handa
2023-08-08 14:38         ` Paul Moore
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 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.