linux-kernel - Re: Friendlier EPERM

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 09 Jan 2013 17:17:41 -0500
From:	Carlos O'Donell <carlos@...temhalted.org>
To:	Eric Paris <eparis@...hat.com>
CC:	Jakub Jelinek <jakub@...hat.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	linux-kernel@...r.kernel.org, libc-alpha@...rceware.org,
	dwalsh@...hat.com, dmalcolm@...hat.com, sds@...ho.nsa.gov,
	segoon@...nwall.com, linux-security-module@...r.kernel.org
Subject: Re: Friendlier EPERM - Request for input

On 01/09/2013 04:09 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 21:59 +0100, Jakub Jelinek wrote:
>> On Wed, Jan 09, 2013 at 12:53:40PM -0800, Casey Schaufler wrote:
>>> I'm suggesting that the string returned by get_extended_error_info()
>>> ought to be the audit record the system call would generate, regardless
>>> of whether the audit system would emit it or not.
>>
>> What system call would that info be for and would it be reset on next
>> syscall that succeeded, or also failed?
>>
>> The thing is, various functions e.g. perform some syscall, save errno, do
>> some other syscall, and if they decide that the first syscall should be what
>> determines the whole function's errno, just restore errno from the saved
>> value and return.  Similarly, various functions just set errno upon
>> detecting some error condition in userspace.
>> There is no 1:1 mapping between many libc library calls and syscalls.
>> So, when would it be safe to call this new get_extended_error_info function
>> and how to determine to which syscall it was relevant?

I asked the same questions as Jakub asked but in a slightly different
formulation (http://cygwin.com/ml/libc-alpha/2013-01/msg00267.html).
 
> I was thinking of it to be the last kernel error.  So if the first and
> that second operation caused the kernel to want to make available
> extended errno information you would end up with the second.  I see this
> is an informative piece of information, not normative.  Not a
> replacement for errno.  I'm hoping for a best effort way to provide
> extended errno information.

IMO Casey's answer is the right solution i.e. whatever the errno
behaviour was.

> It would be really neat for libc to have a way to save and restore the
> extended errno information, maybe even supply its own if it made the
> choice in userspace, but that sounds really hard for the first pass.

Unfortunately without the ability to save/restore the extended
information the best you can do is say "You saw an error, here is
the last N kernel syscalls you made and their error return codes."

You could take a signal at any time and have interposed syscalls,
or you could call a glibc function that makes many syscalls. You
need a way to expose the last N syscalls with errors and hope that
that's enough information for the user to determine the issue.

> I mean it would be great if we could rewrite every system call with a
> cookie so userspace could reliably match things back up, but I just
> don't see that as practical.  Instead we do the best we can and help
> admins and developers most of the time, instead of none of the time.

Agreed.

Cheers,
Carlos.
--
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/