From: Eric Paris <eparis@redhat.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org,
dwalsh@redhat.com, dmalcolm@redhat.com, sds@tycho.nsa.gov,
segoon@openwall.com, linux-security-module@vger.kernel.org
Subject: Re: Friendlier EPERM - Request for input
Date: Wed, 09 Jan 2013 15:32:40 -0500 [thread overview]
Message-ID: <1357763560.1342.7.camel@localhost> (raw)
In-Reply-To: <50EDCFC0.3010401@schaufler-ca.com>
On Wed, 2013-01-09 at 12:14 -0800, Casey Schaufler wrote:
> On 1/9/2013 11:43 AM, Eric Paris wrote:
> > I know many people are worried about information leaks, so I'll right up
> > front say lets add the sysctl to disable the interface for those who are
> > concerned about the metadata information leak. But for most of us I
> > want that data right when it happens, where it happens, so It can be
> > exposed, used, and acted upon by the admin trying to troubleshoot why
> > the shit just hit the fan.
>
> How on earth is your webadmin supposed to match the failure
> of a system call with the content of /proc/8675309/whydiditfail
> at the time of the failure? It's not like he's going to go into
> the apache source and add code to look at what's there.
>
> Unfortunately, what you probably need is an interface that gives
> the program access to the audit records it has generated.
The first thought was wanting to add it by default to perror/strerror in
libc, but libc guys didn't think it reasonable since it couldn't be
save/restored across calls, like errno. Instead I hope for a libc
function, something like char *get_extended_error_info(void), which
outputs a localized string based on the information in the /proc
interface.
Programs like httpd would need to be changed to use this function when
logging denials. Programs like python would use this interface to
populate additional information in the exception they pass up the stack.
I agree that something access to the audit record is appropriate. It's
sorta like what I'm proposing. But audit is not really useful here. It
doesn't collect information about any denial other than LSM. And the
number of DAC or capabilities denials on a normally operating box is, I
expect, quite large. Thus we can't pump them all into audit just on the
unlikely chance something cares. Setting a couple of ints is cheap.
Audit is really nice for people will well defined security goals and
information retention and analysis purposes, but it kinda completely
sucks butt for a normal sysadmin or developer...
-Eric
next prev parent reply other threads:[~2013-01-09 20:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 16:04 Friendlier EPERM - Request for input Eric Paris
2013-01-09 19:43 ` Eric Paris
2013-01-09 20:14 ` Casey Schaufler
2013-01-09 20:32 ` Eric Paris [this message]
2013-01-09 20:53 ` Casey Schaufler
2013-01-09 20:59 ` Jakub Jelinek
2013-01-09 21:09 ` Eric Paris
2013-01-09 22:17 ` Carlos O'Donell
2013-01-21 0:00 ` Eric W. Biederman
2013-01-21 0:59 ` Eric W. Biederman
2013-01-21 1:09 ` Mike Frysinger
2013-01-09 21:12 ` Casey Schaufler
2013-01-09 21:13 ` Eric Paris
2013-01-09 21:36 ` Casey Schaufler
2013-01-10 15:14 ` Tetsuo Handa
2013-01-10 16:34 ` Eric Paris
2013-01-11 13:00 ` Mimi Zohar
2013-01-12 5:08 ` Tetsuo Handa
2013-01-27 14:16 ` Rich Kulawiec
2013-01-12 7:23 ` Rob Landley
2013-01-12 20:27 ` Dr. David Alan Gilbert
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=1357763560.1342.7.camel@localhost \
--to=eparis@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=dmalcolm@redhat.com \
--cc=dwalsh@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=segoon@openwall.com \
/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