linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@redhat.com>,
	Kees Cook <keescook@chromium.org>, Will Drewry <wad@chromium.org>,
	linux-audit@redhat.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions
Date: Tue, 3 Jan 2017 07:53:48 -0600	[thread overview]
Message-ID: <9233ff93-16e7-6852-ec62-cb91af647fd3@canonical.com> (raw)
In-Reply-To: <CALCETrW7sYuUG12DQzgj1pui16KufdBU_3kMw7s3g5oaPpebDg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1888 bytes --]

On 01/02/2017 11:57 PM, Andy Lutomirski wrote:
> On Mon, Jan 2, 2017 at 8:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
>> This patch set creates the basis for auditing information specific to a given
>> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
>> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
>> errno value that will be returned to userspace.
>>
> 
> Not that I'm opposed to the idea, but what's the intended purpose?

Ubuntu has a security sandbox, which includes seccomp as a part of the
confinement strategy, that we're using to confine untrusted third-party
applications. Today, we're using SECCOMP_RET_KILL as the default action
when the applications make a call to a syscall that is not allowed by
the sandbox. It is great from a security perspective but not so great
from the perspective of the application developer as their application
(or in some cases, an interpretor) may work fine without the illegal
syscall but it doesn't get the chance to because it is killed.

In the near future, we want to switch over to using SECCOMP_RET_ERRNO
(the errno is still TBD) as the default action to improve the
application developer experience. The largest remaining blocker is that
there are no audit messages when a SECCOMP_RET_ERRNO action is taken.
Therefore, we can't suggest (to the application developer or to the
user) which sandbox knobs need to be turned to better suite their
application, we can't let the application developer know that a syscall
they're using is illegal outside of them having to debug an odd errno
value, and we can't let the user know of a potentially subverted process
that's under confinement of the sandbox. All of that could be addressed
if SECCOMP_RET_ERRNO actions generated audit messages.

I hope that helps to understand the use case.

Tyler



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

      reply	other threads:[~2017-01-03 13:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-02 16:53 [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Tyler Hicks
2017-01-02 16:53 ` [PATCH 1/2] seccomp: Allow for auditing functionality specific to " Tyler Hicks
2017-01-02 16:53 ` [PATCH 2/2] seccomp: Audit SECCOMP_RET_ERRNO actions with errno values Tyler Hicks
2017-01-02 17:20   ` Steve Grubb
2017-01-02 17:42     ` Tyler Hicks
2017-01-02 18:49       ` Steve Grubb
2017-01-02 22:55         ` Paul Moore
2017-01-02 22:47 ` [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions Paul Moore
2017-01-03  5:56   ` Andy Lutomirski
2017-01-03 19:31     ` Paul Moore
2017-01-03 13:31   ` Tyler Hicks
2017-01-03 19:42     ` Paul Moore
2017-01-03 20:44       ` Kees Cook
2017-01-03 20:53         ` Steve Grubb
2017-01-03 20:54         ` Paul Moore
2017-01-03 21:03           ` Kees Cook
2017-01-03 21:13             ` Paul Moore
2017-01-03 21:21               ` Kees Cook
2017-01-03 21:31                 ` Paul Moore
2017-01-03 21:44                   ` Kees Cook
2017-01-04  1:58                     ` Tyler Hicks
2017-01-04  4:43                       ` Richard Guy Briggs
2017-01-04  6:31                         ` Kees Cook
2017-01-04  2:04       ` Tyler Hicks
2017-01-03  5:57 ` Andy Lutomirski
2017-01-03 13:53   ` Tyler Hicks [this message]

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=9233ff93-16e7-6852-ec62-cb91af647fd3@canonical.com \
    --to=tyhicks@canonical.com \
    --cc=eparis@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=paul@paul-moore.com \
    --cc=wad@chromium.org \
    /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).