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
| ||
|
Date: Wed, 18 Nov 2009 14:33:30 -0500 From: Steve Grubb <sgrubb@...hat.com> To: "Andrew G. Morgan" <morgan@...nel.org> Cc: "Serge E. Hallyn" <serue@...ibm.com>, lkml <linux-kernel@...r.kernel.org>, linux-security-module@...r.kernel.org, Kees Cook <kees.cook@...onical.com>, Andreas Gruenbacher <agruen@...e.de>, Michael Kerrisk <mtk.manpages@...il.com>, George Wilson <gcwilson@...ibm.com>, KaiGai Kohei <kaigai@...gai.gr.jp> Subject: Re: drop SECURITY_FILE_CAPABILITIES? On Wednesday 18 November 2009 01:36:20 pm Andrew G. Morgan wrote: > On Wed, Nov 18, 2009 at 9:49 AM, Steve Grubb <sgrubb@...hat.com> wrote: > > On Wednesday 18 November 2009 11:40:13 am Andrew G. Morgan wrote: > >> >> But back to detecting the capability version number...if I pass 0 as > >> >> the version in the header, why can't the kernel just say oh you want > >> >> the preferred version number, stuff it in the header, and return the > >> >> syscall with success and not EINVAL? > >> > >> This is so a library can understand that it doesn't understand the > >> current ABI. > > > > If user space is passing a NULL for the cap_user_data_t argument, user > > space has a pretty good idea that its not expecting actual capabilities > > to be filled in. My basic point is that there is no way to "correctly" > > use the capabilities API to determine what the preferred version is. > > But older kernels didn't do that. True, but now we have the problem. > >> The intention is for it to fail safe and not blunder on doing > >> "security" related operations with an imperfect idea of the current > >> kernel interface. > >> > >> This is how libcap figures out it can work with the hosting kernel: > > > > capget(0x20080522, 0, NULL) = -1 EFAULT (Bad address) > > I'm not sure what this is supposed to do. This system call takes two > arguments and none of them work as your above snippet suggests. This is from running "strace /usr/sbin/getcap libcap.h". I think strace is splitting arg 1 into its 2 elements within the structure for display purposes. You can strace it yourself and see. :) > SYSCALL_DEFINE2(capget, cap_user_header_t, header, cap_user_data_t, > dataptr) 165 { > 166 int ret = 0; > 167 pid_t pid; > 168 unsigned tocopy; > 169 kernel_cap_t pE, pI, pP; > 170 > 171 ret = cap_validate_magic(header, &tocopy); > 172 if (ret != 0) > 173 return ret; > > ie., two arguments, both of which are pointers. dataptr is not touched > if you supply incorrect magic... The return at line 173 is taken if > header is explored and does not contain the correct magic (ie. > Invalid) - which it overwrites with the kernel-preferred value in the > header, and returns EINVAL... OK, this is the right place to make a fix. Something along the lines of: @@ -169,8 +169,11 @@ SYSCALL_DEFINE2(capget, cap_user_header_ kernel_cap_t pE, pI, pP; ret = cap_validate_magic(header, &tocopy); - if (ret != 0) + if (ret != 0) { + if (ret == -EINVAL && dataptr == NULL) + return 0; return ret; + } if (get_user(pid, &header->pid)) return -EFAULT; > I don't see an EFAULT problem here. It comes when get_user fails above. -Steve -- 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/
Powered by blists - more mailing lists