linux-kernel - Re: [PATCH 1/3] seccomp: Add SECCOMP_RET

lists.openwall.net		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]

Message-ID: <34771527.GTMPbzeFu2@sifl>
Date:	Wed, 19 Dec 2012 10:28:42 -0500
From:	Paul Moore <pmoore@...hat.com>
To:	Corey Bryant <coreyb@...ux.vnet.ibm.com>,
	Will Drewry <wad@...omium.org>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org,
	otubo@...ux.vnet.ibm.com, Kees Cook <keescook@...omium.org>
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/