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]

Message-ID: <20130112202747.GA13942@gallifrey>
Date:	Sat, 12 Jan 2013 20:27:47 +0000
From:	"Dr. David Alan Gilbert" <dave@...blig.org>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, libc-alpha@...rceware.org,
	dwalsh@...hat.com, dmalcolm@...hat.com
Subject: Re: Friendlier EPERM - Request for input

* Eric Paris (eparis@...hat.com) wrote:
> Getting an EPERM/EACCES in userspace really kinda blows.  As a user you
> don't have any idea why you got it.  It could be SELinux, it could be
> rwx bits on the file, it could be a missing capability, it could be an
> ACL, it could be who knows what.  We'd like to start figuring out the
> who knows what and hopefully find a way to expose that to userspace.  My
> initial thought is a small buffer in the task struct in which the kernel
> can dump some data when it is going to send back an EPERM.  I was
> thinking of exposing that data via a /proc/self/task/[tid]/file which
> userspace could poll after an EPERM.  The hope would be to all userspace
> a better understanding of why it failed.  Wouldn't it be nice if instead
> of httpd log just saying 'permission denied' it would be able to say
> 'permision denied because the file was 640"?

It's not just file access that's the problem (although with all the security
layers it's probably one of the more complex ones).

I've wasted way too much time trying to figure out why mmap (for example)
has given me an EINVAL; there are just too many holes you can fall into.

I've wondered in the past about using more bits of errno; making the
standard syscalls mask those out (when -ve), and making a new syscall that
returns the whole lot; that probably doesn't provide you enough for file
stuff though (unless it provided an index into your buffer?).  So that
shouldn't break an existing libc, but a new one would have a chance
at a better errno.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/
--
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/