[PATCH v2] TaskTracker : Simplified thread information tracker.

[Tetsuo Handa]

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() ?



static int selinux_secid_to_secctx(u32 secid, char **secdata, u32 *seclen)
{
	return security_sid_to_context(secid,
				       secdata, seclen);
}

static int smack_secid_to_secctx(u32 secid, char **secdata, u32 *seclen)
{
	struct smack_known *skp = smack_from_secid(secid);

	if (secdata)
		*secdata = skp->smk_known;
	*seclen = strlen(skp->smk_known);
	return 0;
}

int apparmor_secid_to_secctx(u32 secid, char **secdata, u32 *seclen)
{
	/* TODO: cache secctx and ref count so we don't have to recreate */
	struct aa_label *label = aa_secid_to_label(secid);
	int flags = FLAG_VIEW_SUBNS | FLAG_HIDDEN_UNCONFINED | FLAG_ABS_ROOT;
	int len;

	AA_BUG(!seclen);

	if (!label)
		return -EINVAL;

	if (apparmor_display_secid_mode)
		flags |= FLAG_SHOW_MODE;

	if (secdata)
		len = aa_label_asxprint(secdata, root_ns, label,
					flags, GFP_ATOMIC);
	else
		len = aa_label_snxprint(NULL, 0, root_ns, label, flags);

	if (len < 0)
		return -ENOMEM;

	*seclen = len;

	return 0;
}

> 
> 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.SAKURA.ne.jp
used AUDIT_PROCHISTORY instead of LSM hooks, but that thread died there.