lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 19 Dec 2012 10:28:42 -0500
From:	Paul Moore <>
To:	Corey Bryant <>,
	Will Drewry <>
Cc:,,,, Kees Cook <>
Subject: Re: [PATCH 1/3] seccomp: Add SECCOMP_RET_INFO return value

On Wednesday, December 19, 2012 09:56:13 AM Corey Bryant wrote:
> On 12/18/2012 05:22 PM, Will Drewry wrote:
> > while others I've spoken with have been using the audit path to track
> > denied values -- not so great for soft-failures :)
> The audit path would work too but if I understand I think you can only
> learn one syscall per execution.  The nice thing about SECCOMP_RET_INFO
> is that you can easily learn all the syscalls in one execution.

Another quick point about the audit log: on some systems, e.g. tightly secured 
SELinux systems, the audit log is only accessible via a very privileged user 
(Will hints at this below).  Normal users do not have access to, and therefore 
can't make use of, the seccomp related audit records.

> > That aside, I worry that pr_info is the wrong place for a random user
> > on the machine to log to for this, but I may be wrong, rather than a
> > dedicated ringbufffer, etc.  So if this is for a user with privs, then
> > a SECCOMP_RET_AUDIT might make sense.  Feedback to a local user seems
> > tricky in general. I don't know :)  I just decided to deal with it in
> > userland even if it is slightly painful.
> That's a good point.  I don't know which option is better either so if
> anyone else could weigh in on the better approach I'd appreciate it.

I agree with Will's statement about better to deal with the problem in 
userspace when possible, but as Corey pointed out, our experiences with QEMU 
have demonstrated that dealing with the problem exclusively in userspace just 
isn't practical in every case.

Syslog might not be the answer, but RET_TRAP and the audit log aren't very 
good answers either.

paul moore
security and virtualization @ redhat

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists