Re: Friendlier EPERM - Request for input
On Thu, Jan 10, 2013 at 11:34:39AM -0500, Eric Paris wrote: > This is not the point I am arguing. This is not about LSMs, how hard > they are to configure, or how to 'fix' them. It certainly isn't about > how one LSM is better, easier, or superior to another. This is about > getting more information in userspace when operations fail. I'll quote > an off list e-mail I received: > > Friendlier/more complete error messages would eliminate an awful lot of > digging around trying to figure *what* the problem is, preparatory to > discerning *where* the problem is and *how* to fix it. I know I'm a bit late to this, but Eric's quoting me, and I thought I should stand behind my words publicly. I often find myself confronted with systems that I didn't build, haven't maintained, have no documentation for, and are broken in odd/puzzling ways. There's also sometimes a bit of duress due to externally imposed time constraints. I of course don't expect anyone else to solve those problems, but it would be awfully handy if there was a breadcrumb trail to follow. So to borrow Eric's phrase, "getting more information in userspace when operations fail", would be an entirely good thing. I'll defer entirely to others in the discussion thread about how that might be best accomplished, but I'd like to express my full support for the end goal. ---rsk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On Sunday 20 January 2013 19:00:46 Eric W. Biederman wrote: > Carlos O'Donell writes: > > 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. > > Let me propose a different mechanism for getting this to user space > that gives you a save/restore ability. > > When a system call returns with an error we return the error code > in one register and leave the rest of the registers that calling > conventions allow us to stomp unchanged. the syscall ABI is not the same as the calling convention. pretty much all C libraries use inline asm to do syscalls. a few applications do too, but for the most part those have converted to the syscall() library function nowadays since the kernel stopped exporting _syscall[1-6]() macros for apps to use directly. basically, that means you can't change the syscall ABI w/out breaking userspace especially on i386 as it is the most constrained architecture. you might get away with it with others which have a lot of spare regs that pretty much no one uses, but that can be dicey too since you're relying on how code just happens to be generated by gcc. the inline asm declares the syscall args only as inputs. the only output is the return register, and memory/cc are the only clobbers. you could do this in a backwards compatible way by setting a bit in the syscall NR to indicate that userland knows it will get back two values. the kernel will check & clear that bit first before looking up the syscall table. somewhat like how the x32 ABI is handled. not saying i like that idea at all, just providing an alternative that would work w/out breaking userspace. -mike signature.asc Description: This is a digitally signed message part.
Re: Friendlier EPERM - Request for input
ebied...@xmission.com (Eric W. Biederman) writes: > Carlos O'Donell writes: > >> 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. > > Let me propose a different mechanism for getting this to user space > that gives you a save/restore ability. > > When a system call returns with an error we return the error code > in one register and leave the rest of the registers that calling > conventions allow us to stomp unchanged. > > On i386 (probabaly our most constraint architecture) that gives us > 4 32bit registers or 16 bytes/characters to play with. > > Returning either an exteneded error number or a short > string in those extra bytes should be very doable, and largely > backwards compatible. > > Then in userspace for those applications who care you can > have a "struct exteneded_error" that holds the extra information. > > To use that information I expect you want something like: > > char *explain_error(int (*failed_func)(...), int errno, struct extended_error > *error); Hmm. It seems it seems someone else has already written libexplain. http://libexplain.sourceforge.net/ Certainly I would suggest starting there for better explanaitions of why things fail. If you want good error messages certainly some amount of help from user space appears necessary. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
Carlos O'Donell writes: > 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. Let me propose a different mechanism for getting this to user space that gives you a save/restore ability. When a system call returns with an error we return the error code in one register and leave the rest of the registers that calling conventions allow us to stomp unchanged. On i386 (probabaly our most constraint architecture) that gives us 4 32bit registers or 16 bytes/characters to play with. Returning either an exteneded error number or a short string in those extra bytes should be very doable, and largely backwards compatible. Then in userspace for those applications who care you can have a "struct exteneded_error" that holds the extra information. To use that information I expect you want something like: char *explain_error(int (*failed_func)(...), int errno, struct extended_error *error); Where explain_error could possibly deduce things even if there is no side channel information in the kernel. (i.e. You got EPERM because the permissions are 0700 and you don't own the file.) Having the core information returned in registers (that are saved by signal handling) and having a structure of a fixed size that you can save and restore should help. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
* Eric Paris (epa...@redhat.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On 01/09/2013 10:04:23 AM, Eric Paris 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. Adding SELinux, ACL, and capabilities to systems made them so much easier to comprehend, didn't it? (My definition of "secure" includes understanding what the system is doing. Crazy, I know.) We'd like to start figuring out the who knows what and hopefully find a way to expose that to userspace. Obviously the response to having too many mechanisms doing the same thing (badly) is to add a management interface. Piled higher and deeper. But maybe those great minds on the lists can help me think of ways to get Friendlier denials that I haven't thought of. Please. What are you thoughts, concerns, issues? -EPERM was about file permissions. For SELinux and disability bits and whatever they're calling OS/2 extended attributes this week you need -EBUREAUCRACY. Ken Thompson had the insight "files are just a flat sequence of bytes" about the same time he invented subdirectories. Bruce Horn shoehorned icon data into the Lisa filesystem metadata because they hadn't implemented subdirectories yet so they couldn't collate files that way, and apparently standard archive formats like "ELF" and "zip/jar" simply didn't occur to him. (Yes really: http://folklore.org/StoryView.py?project=Macintosh&story=The_Grand_Unified_Model_The_Finder.txt ). Copying Bruce's reversion of Ken's insight because Microsoft blindly copied Apple and now Windows doesn't know how to live without this crutch really doesn't fill me with confidence. Oh well, too late now... -Eric Rob-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
Eric Paris wrote: > On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote: > > The reason I think is that people turn off LSMs because they are using LSMs > > without understanding "what the current configuration is" and/or "how to > > change > > configuration". People do not spend (or cannot afford spending) resources > > for > > understanding LSM's configuration. > > This is not the point I am arguing. This is not about LSMs, how hard > they are to configure, or how to 'fix' them. It certainly isn't about > how one LSM is better, easier, or superior to another. This is about > getting more information in userspace when operations fail. I'll quote > an off list e-mail I received: > > Friendlier/more complete error messages would eliminate an awful lot of > digging around trying to figure *what* the problem is, preparatory to > discerning *where* the problem is and *how* to fix it. I agree that having a mechanism to allow the caller to know the reason of failure would be nice. What I'm worrying is that they will simply disable the LSM (e.g. "setenforce 0") even if users are promptly told (via e.g. perror()) that "Cannot open foo for reading: Denied by SELinux" unless very serious effort to allow users to understand "what the current configuration is" and "how to change configuration" is made. While SELinux provides many boolean configuration options, basic stance of SELinux sounds (at least to me) that "users need not to understand/know SELinux configuration; we won't ask users to understand/know SELinux configuration". This is horrible for enterprise systems because who builds a system and who uses/maintains that system are generally different (and therefore builder's administration skill and user/maintainer's administration skill may drastically differ). The person who builds a system is unlikely contactable when the person who uses/maintains that system encountered a trouble. My fear is that "Friendlier EPERM" results in saving only debugging time until LSM is disabled by the builder/user/maintainer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On Thu, 2013-01-10 at 11:34 -0500, Eric Paris wrote: > Friendlier/more complete error messages would eliminate an awful lot of > digging around trying to figure *what* the problem is, preparatory to > discerning *where* the problem is and *how* to fix it. Agreed, add to the mix of existing issues, with the upstreaming of IMA-appraisal, failure when enforcing integrity. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote: > The reason I think is that people turn off LSMs because they are using LSMs > without understanding "what the current configuration is" and/or "how to > change > configuration". People do not spend (or cannot afford spending) resources for > understanding LSM's configuration. This is not the point I am arguing. This is not about LSMs, how hard they are to configure, or how to 'fix' them. It certainly isn't about how one LSM is better, easier, or superior to another. This is about getting more information in userspace when operations fail. I'll quote an off list e-mail I received: Friendlier/more complete error messages would eliminate an awful lot of digging around trying to figure *what* the problem is, preparatory to discerning *where* the problem is and *how* to fix it. There are so many things that might go into fixing problems in an LSM. That's what you are talking about, but it isn't relevant here. This is about knowing WHAT the problem is, maybe helping with where and how. And this isn't just about LSM. Heck, LSMs are just a small part of it. I want extended errno interface to talk about DAC, capabilities, ACLs, LSMs, everything! > > The audit log is complete crap from a usability PoV. If a web admin is > > TOMOYO's audit log is very useful. TOMOYO is a security tool but is also > useful > for education/training/debugging/development/profiling etc. The TOMOYO audit log is a very poor fit for this as well. I'm not trying to be rude, but there is no reasonable way for applications to use it, it is TOMOYO specific, and it doesn't cover non-LSM errors. I want applications like httpd to be able to put what went wrong in its log message. I want python to be able to get extended information and present that up the stack. Nothing we have today comes close. My proposal isn't perfect, it suffers from the same problems as errno (except even worse because it is harder to save and restore), but at least it will usually be helpful... -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
Eric Paris wrote: > On systems with a strict security policy worried about such things this > would quite reasonably need to be disabled. But most of the reason > people turn off LSMs is because it gets in the way and they get pissed > getting an EPERM, checking rwx bits, having no idea WTF happened, and > then being REALLY pissed at the LSM when they figure out that was the > problem. I want to put it right there, out front, here is what went > wrong for the common case. The reason I think is that people turn off LSMs because they are using LSMs without understanding "what the current configuration is" and/or "how to change configuration". People do not spend (or cannot afford spending) resources for understanding LSM's configuration. > We could if it was worth it make filling in the extended dial > information an LSM hook where you can check on a per denial basis. But > I don't see the need. Have you ever tried TOMOYO's interactive enforcing mode? > The audit log is complete crap from a usability PoV. If a web admin is TOMOYO's audit log is very useful. TOMOYO is a security tool but is also useful for education/training/debugging/development/profiling etc. > trying to figure out why his web server isn't serving out web pages > in /home he's going to look in the web server logs and see EPERM. TOMOYO's interactive enforcing mode allows the administrator to judge whether the web pages in /home should be served or not, before he gets EPERM. > That's it. Now he has to start blindly guessing which of the many > possible reasons for EPERM is his problem. Wouldn't it be better if the > information was actually available? Using the audit log in real time is > a bloody nightmare. TOMOYO's interactive enforcing mode utilizes TOMOYO's audit log in real time. In other words, TOMOYO can interpose syscalls and expose the current syscall which is about to be denied. Useful information is available in real time and is used before getting an EPERM. > As the audit maintainer I know how to use ausearch, > but then again, as the SELinux maintainer I know how to figure out which > of the many possibilities from EPERM are the cause. But I want to make > it easier for a normal admin to figure that out. The problem I think is that people don't understand "what the current configuration is" and/or "how to change configuration". > > 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. TOMOYO is exposing useful information in real time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
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 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. 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. 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. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On 1/9/2013 1:13 PM, Eric Paris wrote: > On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote: > >> Let me try again, I think I didn't quite get the idea across. >> >> 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. >> If the audit record doesn't have the information you need we should >> fix the audit system to provide it. Any bit of the information in >> the audit record might be relevant, and your admin or developer might >> need to see it. >> >> I'm suggesting using the audit record because there are tools to >> examine them and it's a pity to use a different format instead of >> fixing the one that's already there. > I get the point. My problem with using audit records is that they have > to be stored on disk, forever. We have to store a record on disk for > EVERY denial because of rwx bits, acls, capabilities, LSM, etc. We > don't do that today and I'm scared of disk growth explosion. Then we > could have a kernel interface, say get_last_audit_record(), which could > query the audit system for that record number. > > A thought on disk size explosion might be something like generating > these records in the kernel and just store them in the task struct until > some later point in time. Yes! This is exactly what I'm suggesting. > If userspace calls get_last_audit_record() we > might be able to dump the record to auditd. No! Have reading /proc/self/whatwentwrong return the audit record associated with the errno last set by the kernel. > If another record comes > along we have to free the last one and replace it. Lot more of a perf > hit than setting a couple of ints and taking the hit at the time when > userspace actually wants to collect/use this information. > > But are we just building up a rube goldburg machine? I don't see a > problem storing the last audit record if it exists, but I don't like > making audit part of the normal workflow. I'd do it if others like that > though > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
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? Jakub -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote: > Let me try again, I think I didn't quite get the idea across. > > 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. > If the audit record doesn't have the information you need we should > fix the audit system to provide it. Any bit of the information in > the audit record might be relevant, and your admin or developer might > need to see it. > > I'm suggesting using the audit record because there are tools to > examine them and it's a pity to use a different format instead of > fixing the one that's already there. I get the point. My problem with using audit records is that they have to be stored on disk, forever. We have to store a record on disk for EVERY denial because of rwx bits, acls, capabilities, LSM, etc. We don't do that today and I'm scared of disk growth explosion. Then we could have a kernel interface, say get_last_audit_record(), which could query the audit system for that record number. A thought on disk size explosion might be something like generating these records in the kernel and just store them in the task struct until some later point in time. If userspace calls get_last_audit_record() we might be able to dump the record to auditd. If another record comes along we have to free the last one and replace it. Lot more of a perf hit than setting a couple of ints and taking the hit at the time when userspace actually wants to collect/use this information. But are we just building up a rube goldburg machine? I don't see a problem storing the last audit record if it exists, but I don't like making audit part of the normal workflow. I'd do it if others like that though -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On 1/9/2013 12:59 PM, 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? It ought to be the same system call that generated the contents of errno. > > 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. Whichever system call generated the content of errno. If that means the functions that currently save away errno have to save away the audit text, that's what it would have to do. Simple. Not necessarily pleasant, but simple. > Similarly, various functions just set errno upon > detecting some error condition in userspace. Then get_extended_error_info should return NULL. Or, if the library code prefers, creates its own audit record in valid audit record format. > There is no 1:1 mapping between many libc library calls and syscalls. Truth. I'm suggesting the get_extended_error_info behavior match the errno behavior. > 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? Any time you could look at errno you should be able to get a matching explanation from get_extended_error_info. > > Jakub > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On 1/9/2013 12:32 PM, Eric Paris wrote: > 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... Let me try again, I think I didn't quite get the idea across. 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. If the audit record doesn't have the information you need we should fix the audit system to provide it. Any bit of the information in the audit record might be relevant, and your admin or developer might need to see it. I'm suggesting using the audit record because there are tools to examine them and it's a pity to use a different format instead of fixing the one that's already there. > -Eric > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
On 1/9/2013 11:43 AM, Eric Paris wrote: >> On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote: >>> Getting an EPERM/EACCES in userspace really kinda blows. As a user you >>> don't have any idea why you got it. > Stephen Smalley wrote: >> What if the denial was due to lacking sufficient permission to stat >> the file (in which case you shouldn't leak the file's attributes to the >> caller)? >> >> Also, the present inability of (unprivileged) userspace to distinguish >> DAC from MAC denials is relied upon to avoid any covert channel when >> the DAC check happens before the MAC check, as otherwise you leak >> information about the DAC attributes. If you are going to indicate to >> all of userspace whether it was DAC or MAC, you have to make sure that >> the MAC check / LSM hook always comes first in every case. Which then >> leads to lots of unnecessary MAC audit messages that would have been >> denied by DAC anyway. > I'd have to fall back to my original thought about who to expose this > information to: > >>> Another thought was that some people might want to turn off the ability >>> to get this information. I don't see a reason a sysctl couldn't be used >>> to disable extended errno information if the admin so chose. > On systems with a strict security policy worried about such things this > would quite reasonably need to be disabled. But most of the reason > people turn off LSMs is because it gets in the way and they get pissed > getting an EPERM, checking rwx bits, having no idea WTF happened, and > then being REALLY pissed at the LSM when they figure out that was the > problem. I want to put it right there, out front, here is what went > wrong for the common case. > > I mean, we sorta, kinda sometimes, poorly give this information. Isn't > DAC usually EPERM and LSMs usually EACCES. It's supposed (from POSIX) to be that EACCES means the system denied you access based on normal policy and EPERM means you tried something that you could only do with privilege, and failed. Opening a file with mode bits that deny access should get EACCES. Changing the mode bits on a file you don't own should get EPERM. > From a DAC PoV exposing the > DAC info is completely reasonable. You can't hide a stat(), even > setting chmod 000. So this is an LSM issue. Not an issue for > DAC/Capabilities/ACLs. We can add an LSM hook on the /proc file to make > sure nothing can get the data even if the global sysctl allows such > access. > > We could if it was worth it make filling in the extended dial > information an LSM hook where you can check on a per denial basis. But > I don't see the need. > >> Privileged userspace already has a way to identify when it was a MAC >> denial, via the audit logs. But those are considered >> security-sensitive, and so exposing that same information to >> unprivileged userspace will be a problem. > The audit log is complete crap from a usability PoV. If a web admin is > trying to figure out why his web server isn't serving out web pages > in /home he's going to look in the web server logs and see EPERM. > That's it. Now he has to start blindly guessing which of the many > possible reasons for EPERM is his problem. Wouldn't it be better if the > information was actually available? Using the audit log in real time is > a bloody nightmare. As the audit maintainer I know how to use ausearch, > but then again, as the SELinux maintainer I know how to figure out which > of the many possibilities from EPERM are the cause. But I want to make > it easier for a normal admin to figure that out. > > 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. > > -Eric > > -- > To unsubscribe from this list: send the line "unsubscribe > linux-security-module" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Friendlier EPERM - Request for input
>On Wed, 2013-01-09 at 11:04 -0500, Eric Paris wrote: > >Getting an EPERM/EACCES in userspace really kinda blows. As a user you > >don't have any idea why you got it. Stephen Smalley wrote: > What if the denial was due to lacking sufficient permission to stat > the file (in which case you shouldn't leak the file's attributes to the > caller)? > > Also, the present inability of (unprivileged) userspace to distinguish > DAC from MAC denials is relied upon to avoid any covert channel when > the DAC check happens before the MAC check, as otherwise you leak > information about the DAC attributes. If you are going to indicate to > all of userspace whether it was DAC or MAC, you have to make sure that > the MAC check / LSM hook always comes first in every case. Which then > leads to lots of unnecessary MAC audit messages that would have been > denied by DAC anyway. I'd have to fall back to my original thought about who to expose this information to: > >Another thought was that some people might want to turn off the ability > >to get this information. I don't see a reason a sysctl couldn't be used > >to disable extended errno information if the admin so chose. On systems with a strict security policy worried about such things this would quite reasonably need to be disabled. But most of the reason people turn off LSMs is because it gets in the way and they get pissed getting an EPERM, checking rwx bits, having no idea WTF happened, and then being REALLY pissed at the LSM when they figure out that was the problem. I want to put it right there, out front, here is what went wrong for the common case. I mean, we sorta, kinda sometimes, poorly give this information. Isn't DAC usually EPERM and LSMs usually EACCES. From a DAC PoV exposing the DAC info is completely reasonable. You can't hide a stat(), even setting chmod 000. So this is an LSM issue. Not an issue for DAC/Capabilities/ACLs. We can add an LSM hook on the /proc file to make sure nothing can get the data even if the global sysctl allows such access. We could if it was worth it make filling in the extended dial information an LSM hook where you can check on a per denial basis. But I don't see the need. > Privileged userspace already has a way to identify when it was a MAC > denial, via the audit logs. But those are considered > security-sensitive, and so exposing that same information to > unprivileged userspace will be a problem. The audit log is complete crap from a usability PoV. If a web admin is trying to figure out why his web server isn't serving out web pages in /home he's going to look in the web server logs and see EPERM. That's it. Now he has to start blindly guessing which of the many possible reasons for EPERM is his problem. Wouldn't it be better if the information was actually available? Using the audit log in real time is a bloody nightmare. As the audit maintainer I know how to use ausearch, but then again, as the SELinux maintainer I know how to figure out which of the many possibilities from EPERM are the cause. But I want to make it easier for a normal admin to figure that out. 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. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Friendlier EPERM - Request for input
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"?
I was thinking this buffer would look something like (very pseudo codie)
struct friendly_response {
enum { NONE, CAPABILITIES, SELINUX, FILE_PERMS } type;
union {
struct capabilities {
int cap;
};
struct selinux {
__u32 source_label
__u32 target_label
__u32 operation;
__u32 tclass;
};
struct file_perms {
int uid;
int gid;
int file_uid;
int file_gid;
int file_mode;
};
};
};
The idea being that the buffer should only hold stateless data which can
be overwritten or destroyed on the next EPERM. Reading the proc file
could then translate that into something a little more useful, but
hopefully still computer friendly enough that it can be translated and
useful to a user/developer. So after a denial from file permissions the
proc file would return a string like:
3 500 500 0 0 0640
^ ^ ^ ^ ^ ^--- Mode
| | | | |--- File Gid
| | | |---File Uid
| | |--- User Gid
| |---User Uid
|--- Type for failure (file perms)
Or from SELinux:
2 unconfined_u:unconfined_r:unconfined_t:s0 system_u:system_r:system_t:s0 {
read } file
This would take patching hundreds of call sites in the kernel to fill
the buffer. But just getting extended denial information in a couple of
the hot spots would be a huge win. Put it in capable(), LSM hooks, the
open() syscall and path walk code.
It was pointed out that this isn't perfect, and I'm well aware of that.
Lots of userspace libraries do things like save errno, make other kernel
calls which could overwrite the buffer, then pass errno up the stack. I
don't believe there is much that can done about that. Other than
userspace trying to save the extended error information as well?
One suggestion was to make it a ring buffer of some configurable size
instead. I'm not sure how a program could find the 'right' message in
the ring buffer, but it is a thought to help the problem of intervening
kernel calls overwriting the last extended error info. I was pointed to
the win32 api for getLastError() as something to look at. This API is
mostly like errno/strerror in libc, except without the easy ability to
save it for later. My new proposed API would have the same problems.
No 'easy' way to save it for later. (also getLastError() doesn't pass
any kind of extended information, so it seems to solve a different
problem and I haven't seen any OS that is doing this, so point me to
places I can learn)
Another thought was that some people might want to turn off the ability
to get this information. I don't see a reason a sysctl couldn't be used
to disable extended errno information if the admin so chose.
But maybe those great minds on the lists can help me think of ways to
get Friendlier denials that I haven't thought of. Please. What are you
thoughts, concerns, issues?
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
