re: [PATCH] fexecve
On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote: On Fri, 16 Nov 2012 08:34:29 + David Laight da...@l8s.co.uk wrote: On Thu, Nov 15, 2012 at 10:14:18PM +0100, Joerg Sonnenberger wrote: Frankly, I still don't see the point why something would want to use it. How about running a staticly linked executable inside a chroot without needed the executable itself to do the chroot. What does this gain over passing a filename around? (NB. I'm not claiming that's an entirely safe model either, but it's already possible). You don't need the executable image inside the chroot. in other words: any executable visible on the system can be make present inside the chroot. i don't like this feature and would rather that netbsd did not implement it. .mrg.
Re: fexecve, round 2
On Sat, Nov 17, 2012 at 11:48:20AM +0100, Emmanuel Dreyfus wrote: Here is an attempt to address what was said about implementing fexecve() fexecve() checks that the vnode underlying the fd : - is of type VREG - grants execution right O_EXEC cause open()/openat() to fail if the file mode does not grant execute rights There are security concerns with fd passed to chrooted processes, which could help executing code. Here is a proposal for chrooted processes: 1) if current process and executed vnode have different roots, then fexecve() fails I'm not sure how you were intending determining that. You can follow .. for directories, but not files. 2) if the fd was not open with O_EXEC, fexecve() fails. First point avoids executing code from outside the chroot Second point enforces W^X inside the chroot. If we don't want to allow chroot'ed process to exec a file that is outside the chroot, then maybe the kernel could hold a reference to the directory vnode (in the file vnode) whenever a file is opened for execute (including the existing exec() family of calls calls). As well as being used to police fexecve() withing a chroot, it could be used by the dynamic linker for $ORIGIN processing (Probably by some special flags to openat().). David -- David Laight: da...@l8s.co.uk
Re: fexecve, round 2
Rhialto rhia...@falu.nl wrote: The definition is really vague. As I understand, nothing forbids opening O_EXEC|O_RDWR. Applications shall specify exactly one of the first five values (file access modes) below in the value of oflag: Right, I missed that point. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Can't load solaris and zfs module in Xen DomU
Hello all, I have a problem to get ZFS running in a NetBSD 6.0 Xen DomU. I installed the DomU over the normal way and recompiled the NetBSD DomU kernel with MODULAR option so that it can load modules. I copied the kernel image to Dom0 (Debian Squeeze Kernel 2.6.32/Xen 4.0) and booted up the DomU which works fine. But when I try to load the modules I get the following error as well as for solaris and zfs module: kobj_load, 416: [%M/solaris/solaris.kmod]: linker error: out of memory modload: Cannot allocate memory kobj_load, 416: [%M/zfs/zfs.kmod]: linker error: out of memory modload: Cannot allocate memory So does somebody know how I could fix this problem and is it possible to compile ZFS statically into the kernel? Best Regards
Re: fexecve, round 2
On Sat, Nov 17, 2012 at 06:42:50PM -0500, Thor Lancelot Simon wrote: O_EXEC cause open()/openat() to fail if the file mode does not grant execute rights There are security concerns with fd passed to chrooted processes, which could help executing code. Here is a proposal for chrooted processes: 1) if current process and executed vnode have different roots, then fexecve() fails 2) if the fd was not open with O_EXEC, fexecve() fails. This appears to contradict either the description of O_EXEC in the standard, or the standard's rationale for adding fexecve(). The standard says O_EXEC causes the file to be open for execution only. In other words, O_EXEC means you can't read nor write the file. Now the rationale for fexecve() doesn't hold, since you cannot read from the fd, then exec from it without a reopen. Further, requiring O_EXEC would seem to directly contravene the standard's language about fexecve()'s behavior. The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. This to me is illustrative of the danger of slavishly substituting the XPG group's technical judgment for our own. They frequently standardise poorly thought out Linux hacks; twisting ourselves into knots to make what they half-designed safe, at which point it doesn't conform to their standard any more, does not seem like a good general plan to me. Indeed. -- David A. Holland dholl...@netbsd.org
Re: Can't load solaris and zfs module in Xen DomU
On Apr 10, 1:26pm, Lukas Laukamp wrote: } } I have a problem to get ZFS running in a NetBSD 6.0 Xen DomU. Modules aren't supported with Xen at this time. } I installed the DomU over the normal way and recompiled the NetBSD DomU } kernel with MODULAR option so that it can load modules. I copied the } kernel image to Dom0 (Debian Squeeze Kernel 2.6.32/Xen 4.0) and booted } up the DomU which works fine. But when I try to load the modules I get } the following error as well as for solaris and zfs module: How did you compile these modules? One of the issues with Xen and modules is that Xen changes a bunch of kernel ABIs. That means you need to compile modules with -DXEN (which won't happen by default) to even try loading modules. If you don't do this, and you successfully load a module, then there is a very good chance of the system going boom! } So does somebody know how I could fix this problem and is it possible to } compile ZFS statically into the kernel? I haven't been following ZFS that closely, as currently it isn't even close to being in production ready state, but something in the back of my mind says it isn't possible, possibly due to licensing issues. }-- End of excerpt from Lukas Laukamp
Re: fexecve, round 2
David Holland dholland-t...@netbsd.org wrote: The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. Do you have something correct to sugest? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: fexecve, round 2
On Sun, Nov 18, 2012 at 06:16:00PM +, David Holland wrote: This appears to contradict either the description of O_EXEC in the standard, or the standard's rationale for adding fexecve(). The standard says O_EXEC causes the file to be open for execution only. In other words, O_EXEC means you can't read nor write the file. Now the rationale for fexecve() doesn't hold, since you cannot read from the fd, then exec from it without a reopen. Further, requiring O_EXEC would seem to directly contravene the standard's language about fexecve()'s behavior. The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. Also it seems that the specification of O_SEARCH (and I think the implementation we just got, too) is flawed in the same way - it is performing access checks at use time instead of at open time. (Also the implementation we just got seems to be missing any access check at open time -- this seems entirely wrong.) -- David A. Holland dholl...@netbsd.org
Re: Can't load solaris and zfs module in Xen DomU
Am 18.11.2012 19:26, schrieb John Nemeth: On Apr 10, 1:26pm, Lukas Laukamp wrote: } } I have a problem to get ZFS running in a NetBSD 6.0 Xen DomU. Modules aren't supported with Xen at this time. } I installed the DomU over the normal way and recompiled the NetBSD DomU } kernel with MODULAR option so that it can load modules. I copied the } kernel image to Dom0 (Debian Squeeze Kernel 2.6.32/Xen 4.0) and booted } up the DomU which works fine. But when I try to load the modules I get } the following error as well as for solaris and zfs module: How did you compile these modules? One of the issues with Xen and modules is that Xen changes a bunch of kernel ABIs. That means you need to compile modules with -DXEN (which won't happen by default) to even try loading modules. If you don't do this, and you successfully load a module, then there is a very good chance of the system going boom! } So does somebody know how I could fix this problem and is it possible to } compile ZFS statically into the kernel? I haven't been following ZFS that closely, as currently it isn't even close to being in production ready state, but something in the back of my mind says it isn't possible, possibly due to licensing issues. }-- End of excerpt from Lukas Laukamp I don't recompiled the kernel modules, I simply tried the modules which was binary shipped with the base system. So I will try to recompile the modules and hope that there will be a way to get it working. Or is there an alternativ filesystem which has modern design and would be usable on much platforms? So for ZFS there is support in FreeBSD, Linux and I think read only support on Windows. So I thought it would be a good choice. Best Regards
Re: fexecve, round 2
On Sun, Nov 18, 2012 at 07:42:43PM +0100, Emmanuel Dreyfus wrote: The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. Do you have something correct to sugest? Not off the top of my head. Rushing it through and going off half-cocked as a result is how these things get to us broken in the first place; let's not repeat the mistake. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
On Sat, 17 Nov 2012 21:45:02 + David Laight da...@l8s.co.uk wrote: On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote: What does this gain over passing a filename around? (NB. I'm not claiming that's an entirely safe model either, but it's already possible). You don't need the executable image inside the chroot. I don't believe that's intended to be possible, and if it is, I'm not sure it's a gain. -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: Can't load solaris and zfs module in Xen DomU
On Apr 10, 2:27pm, Lukas Laukamp wrote: } Am 18.11.2012 19:26, schrieb John Nemeth: } On Apr 10, 1:26pm, Lukas Laukamp wrote: } } } } I have a problem to get ZFS running in a NetBSD 6.0 Xen DomU. } }Modules aren't supported with Xen at this time. } } } I installed the DomU over the normal way and recompiled the NetBSD DomU } } kernel with MODULAR option so that it can load modules. I copied the } } kernel image to Dom0 (Debian Squeeze Kernel 2.6.32/Xen 4.0) and booted } } up the DomU which works fine. But when I try to load the modules I get } } the following error as well as for solaris and zfs module: } }How did you compile these modules? One of the issues with Xen and } modules is that Xen changes a bunch of kernel ABIs. That means you } need to compile modules with -DXEN (which won't happen by default) to } even try loading modules. If you don't do this, and you successfully } load a module, then there is a very good chance of the system going } boom! } } } So does somebody know how I could fix this problem and is it possible to } } compile ZFS statically into the kernel? } }I haven't been following ZFS that closely, as currently it isn't } even close to being in production ready state, but something in the } back of my mind says it isn't possible, possibly due to licensing } issues. } } I don't recompiled the kernel modules, I simply tried the modules which That definitely won't work. } was binary shipped with the base system. So I will try to recompile the } modules and hope that there will be a way to get it working. Or is there } an alternativ filesystem which has modern design and would be usable on } much platforms? So for ZFS there is support in FreeBSD, Linux and I } think read only support on Windows. So I thought it would be a good choice. FAT works on all platforms, but is hardly modern. I don't think there is a modern file system that works on all platforms. You're going to have to be more specific. Also, take a look in pkgsrc/filesystems. There are things in there that might be useful, such as fuse-ntfs-3g. }-- End of excerpt from Lukas Laukamp
Re: [PATCH] fexecve
On Sun, Nov 18, 2012 at 07:27:27PM +, Julian Yon wrote: On Sat, 17 Nov 2012 21:45:02 + David Laight da...@l8s.co.uk wrote: On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote: What does this gain over passing a filename around? (NB. I'm not claiming that's an entirely safe model either, but it's already possible). You don't need the executable image inside the chroot. I don't believe that's intended to be possible, and if it is, I'm not sure it's a gain. I actually think it might be, if it didn't run the risk of blowing up code that wasn't written to expect it. If we're going to commit this syscall at all, I think it should be accompanied by a new socket option for unix domain sockets, which defaults to off, but if explicitly set to on, allows file descriptors passed across the socket to be used for exec. Thor
Re: fexecve, round 2
On Sun, 18 Nov 2012 18:16:00 + David Holland dholland-t...@netbsd.org wrote: On Sat, Nov 17, 2012 at 06:42:50PM -0500, Thor Lancelot Simon wrote: Further, requiring O_EXEC would seem to directly contravene the standard's language about fexecve()'s behavior. The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. What if the only process that was allowed to fexecve was the one which opened the fd (or possibly extend this to children, but I'm not sure if that's safe), and any other failed with EBADF? Seems to me this would allow the intended usage (tenuous as the rationale is) while closing the chroot based holes that have been discussed. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
On Sun, 18 Nov 2012 14:31:29 -0500 Thor Lancelot Simon t...@panix.com wrote: On Sun, Nov 18, 2012 at 07:27:27PM +, Julian Yon wrote: On Sat, 17 Nov 2012 21:45:02 + David Laight da...@l8s.co.uk wrote: You don't need the executable image inside the chroot. I don't believe that's intended to be possible, and if it is, I'm not sure it's a gain. I actually think it might be, if it didn't run the risk of blowing up code that wasn't written to expect it. As I've clearly missed it, which text in the spec suggests that? I don't see chroot mentioned anywhere. If we're going to commit this syscall at all, I think it should be accompanied by a new socket option for unix domain sockets, which defaults to off, but if explicitly set to on, allows file descriptors passed across the socket to be used for exec. Or just flag all descriptors passed over sockets as non-executable, i.e. implement the call but prevent that particular pattern. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
On Nov 18, 2012, at 11:31 AM, Thor Lancelot Simon wrote: On Sun, Nov 18, 2012 at 07:27:27PM +, Julian Yon wrote: On Sat, 17 Nov 2012 21:45:02 + David Laight da...@l8s.co.uk wrote: On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote: What does this gain over passing a filename around? (NB. I'm not claiming that's an entirely safe model either, but it's already possible). You don't need the executable image inside the chroot. I don't believe that's intended to be possible, and if it is, I'm not sure it's a gain. I actually think it might be, if it didn't run the risk of blowing up code that wasn't written to expect it. If we're going to commit this syscall at all, I think it should be accompanied by a new socket option for unix domain sockets, which defaults to off, but if explicitly set to on, allows file descriptors passed across the socket to be used for exec. I assume that O_EXEC would need to be defined as 3 so that O_ACCMODE will work properly. O_SEARCH would also need to be defined as an alias of O_EXEC (I don't think the current definition we use is correct). Given that, you can't open a file for read exec, just either read or just exec. So how would verification work again? Seems to me you need a fcntl that would allow you to change the access mode of the file descriptor. One use of fexecve I can see is with named; it knows that it will need to fork/exec a few helper programs. It can open these programs before doing the chroot and then use fexecve to invoke leaving no executables inside the chroot as all. So that if you managed to get compromise the named process, there is nothing named can do since in the chroot there is nothing to run.
Re: fexecve, round 2
On Sun, Nov 18, 2012 at 06:51:51PM +, David Holland wrote: This appears to contradict either the description of O_EXEC in the standard, or the standard's rationale for adding fexecve(). The standard says O_EXEC causes the file to be open for execution only. In other words, O_EXEC means you can't read nor write the file. Now the rationale for fexecve() doesn't hold, since you cannot read from the fd, then exec from it without a reopen. Further, requiring O_EXEC would seem to directly contravene the standard's language about fexecve()'s behavior. The standard is clearly wrong on a number of points and doesn't match the historical design and behavior of Unix. Let's either implement something correct, or not implement it at all. Also it seems that the specification of O_SEARCH (and I think the implementation we just got, too) is flawed in the same way - it is performing access checks at use time instead of at open time. So, for the record, I think none of these flags should be added unless they behave the same way opening for write does -- the flag cannot be set except at open time, and only if the opening process has permission to make the selected type of access; once opened the resulting file handle functions as a capability that allows the selected type of access. Anything else creates horrible inconsistencies and violates the principle of least surprise, both of which are not acceptable as part of the access control system. Also, it obviously needs to be possible to open files O_RDONLY|O_EXEC for O_EXEC to be useful, and open directories O_RDONLY|O_SEARCH, and so forth. I don't know what POSIX may have been thinking when they tried to forbid this but forbidding it makes about as much sense as forbidding O_RDWR, maybe less. Someone needs to sit down and figure out what restrictions need to be applied to fd passing to make this safe, both in general and in connection with chroot. One point riastradh@ raised is that if you get a fd for a directory outside your current chroot, you shouldn't be able to use it to openat() or with any of the *at() calls. There is currently no mechanism in place to enforce this. I have a feeling that what we want may be not a restriction on fd-passing sockets or a restriction on file handles, but a restriction on chroots. Also there was a thread back in February titled O_NOACCESS that everyone interested in this stuff should review. (Also the implementation we just got seems to be missing any access check at open time -- this seems entirely wrong.) It turns out to be unexploitable but it's definitely wrong in several ways (unrelated to whether its semantics are poorly chosen); I have asked for it to be reverted. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
On Sun, 18 Nov 2012 14:08:05 -0800 Matt Thomas m...@3am-software.com wrote: Given that, you can't open a file for read exec, just either read or just exec. So how would verification work again? Seems to me you need a fcntl that would allow you to change the access mode of the file descriptor. Incredibly, the spec defines the illogical behaviour: “Since execute permission is checked by fexecve(), the file description fd need not have been opened with the O_EXEC flag. However, if the file to be executed denies read and write permission for the process preparing to do the exec, the only way to provide the fd to fexecve() will be to use the O_EXEC flag when opening fd. In this case, the application will not be able to perform a checksum test since it will not be able to read the contents of the file.” i.e. If you want to read and exec, you open with O_RDONLY. If you don't have read rights you can open with O_EXEC instead, and you can't read the file you just opened; it merely provides a mechanism to pointlessly use fexecve. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
