Re: fexecve, round 3
On Mon, Nov 26, 2012 at 03:22:42AM +0100, Emmanuel Dreyfus wrote:
> David Laight wrote:
>
> > Given a chrooted process would need a helping process outside the
> > chroot (to pass it the fd), why is allowing the chrooted proccess to
> > exec something any different from it arranging to get the helper
> > to do it?
>
> Yes, I agree there is no security hazard introduced: if help from a
> process outside the chroot is assumed, there are already many ways to
> cirumvent chroot security.
And I strongly disagree. We've discussed this at painful length in
the earlier threads on this topic and I don't really, at this time,
want to restate the entire discussion; nor do I think I should need to.
I think this is an unfortunate effect of the way we are discussing
this ("round 1", "round 2", "round 3", each as a separate thread
starting with a call for anyone objecting to restate their objections
to this code going into the tree). There have been many objections,
some subtle and not trivial to restate, and much discussion besides
of the broken nature of this specification itself. Why must we go
'round in circles? NetBSD's only blanket statement on standards
conformance of which I am aware is that NetBSD tries to confirm to
"reasonable" standards, specifically calling out the ancestor of
the standard we're talking about here as an "unreasonable" one.
Why should this discussion take place under what seems to be the
basic assumption that if those opposed to this code going into
the tree can simply be forced to talk until they're sick of talking
any more, these interfaces should go into the tree because they're
(poorly) described in some standard, somewhere? That seems wrong.
Thor
Re: fexecve, round 3
David Laight wrote: > Given a chrooted process would need a helping process outside the > chroot (to pass it the fd), why is allowing the chrooted proccess to > exec something any different from it arranging to get the helper > to do it? Yes, I agree there is no security hazard introduced: if help from a process outside the chroot is assumed, there are already many ways to cirumvent chroot security. > FWIW IIRC the standard says that O_EXEC can't be applied with O_READONLY > (Or O_RDWR) but does it say that you can't read from a file opened O_EXEC ? I understand you could not, and this bit is annoying to implement. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: fexecve, round 3
On Sun, Nov 25, 2012 at 11:47:14PM +, David Laight wrote: > > On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote: > > > > > >> Does everyone agrees on this interpretation? If we do, next steps are > > >> - describe threats this introduce to chrooted processes > > Given a chrooted process would need a helping process outside the > chroot (to pass it the fd), why is allowing the chrooted proccess to > exec something any different from it arranging to get the helper > to do it? > > I think it can only matter if the uid of the chroot is root. > Even then you could (probably) do nothing you couldn;t do by > mmaping some anon space with exec permissions and writing code to it. This thread has been a little long so I am not sure if the setuid programs have been adequately addressed but certainly it is not necessarily safe to execute those in a chroot(2)ed environment as many of them will have assumptions about files such as /etc/spwd.db and so on. We should not just consider setuid programs that we ship but also designs that previously were safe that this model would make unsafe. Another example that I've seen people do is putting secret information such as passwds into programs and give them mode 111 so that it is not easy to read the information. Granted, it doesn't make it terribly difficult to get the information but it still might not be appropriate to allow chrooted applications to exec these programs as I don't think that even if passed an fd that they could mmap(2) and jump. -- Roland Dowdeswell http://Imrryr.ORG/~elric/
Re: fexecve, round 3
On Sun, Nov 25, 2012 at 07:54:59PM +, Christos Zoulas wrote: > > > >> Does everyone agrees on this interpretation? If we do, next steps are > >> - describe threats this introduce to chrooted processes Given a chrooted process would need a helping process outside the chroot (to pass it the fd), why is allowing the chrooted proccess to exec something any different from it arranging to get the helper to do it? I think it can only matter if the uid of the chroot is root. Even then you could (probably) do nothing you couldn;t do by mmaping some anon space with exec permissions and writing code to it. FWIW IIRC the standard says that O_EXEC can't be applied with O_READONLY (Or O_RDWR) but does it say that you can't read from a file opened O_EXEC ? David -- David Laight: da...@l8s.co.uk
core statement on fexecve, O_EXEC, and O_SEARCH
The NetBSD core group has considered adding the fexecve(2) or fexecve(3) syscall or function, and adding new O_EXEC and O_SEARCH open(2) flags. These new features may be useful, but their security properties are not well understood. The core group is of the opinion that these new features should not be added to NetBSD until there is a design that discusses their security properties, the way they interact with each other and existing features, and addresses the security concerns. Designs that are slightly incompatible with other operating systems or with POSIX need not be ruled out; for example, it may be reasonable to make fexecve() fail if the fd was not opened with certain flags, or to automatically clear certain flags when the fd is passed from one process to another. The fexecve function could be implemented entirely in libc, via execve(2) on a file name of the form "/proc/self/fd/". Any security concerns around fexecve() also apply to exec of /proc/self/fd/. If necessary, the open(2) syscall could be versioned so that O_RDONLY is no longer defined as zero. -- Alan Barrett, on behalf of core
Re: fexecve, round 3
>>> O_EXEC is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR >> - simply don't include this poorly-designed functionality in NetBSD. > Unless you want to change O_RDONLY to be non-zero and version all the > syscalls that use it :-) I don't see any need to do that, unless they were crazy enough to _require_ that the implementation error out if O_EXEC is combined with one of the other three. (I would expect that to just be an application error, which an implementation may choose to assign meaning to.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: fexecve, round 3
In article <20121125152520.ga17...@panix.com>, Thor Lancelot Simon wrote: >On Sat, Nov 24, 2012 at 06:53:16PM +0100, Emmanuel Dreyfus wrote: >> Let's try to move forward, and I will start will a sum up of what I >> understand from the standard. It would be nice if we could at least >> reach consensus on standard interpretation. > >I think your interpretation of the standard is correct. The >particularly problematic part is: > >> O_EXEC is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR > >This -- along with the basic shift from checking permissions when a handle >to an object is obtained to checking them when it's used -- is exemplary of >the poor design that seems to have gone into this set of "features". > >> Does everyone agrees on this interpretation? If we do, next steps are >> - describe threats this introduce to chrooted processes >> - decide if they are acceptable and if they are not, propose mitigation. > >I think you left out part of the solution space: > > - simply don't include this poorly-designed functionality in NetBSD. Unless you want to change O_RDONLY to be non-zero and version all the syscalls that use it :-) christos
Re: fexecve, round 3
On Sat, Nov 24, 2012 at 06:53:16PM +0100, Emmanuel Dreyfus wrote: > Let's try to move forward, and I will start will a sum up of what I > understand from the standard. It would be nice if we could at least > reach consensus on standard interpretation. I think your interpretation of the standard is correct. The particularly problematic part is: > O_EXEC is mutually exclusive with O_RDONLY, O_WRONLY, or O_RDWR This -- along with the basic shift from checking permissions when a handle to an object is obtained to checking them when it's used -- is exemplary of the poor design that seems to have gone into this set of "features". > Does everyone agrees on this interpretation? If we do, next steps are > - describe threats this introduce to chrooted processes > - decide if they are acceptable and if they are not, propose mitigation. I think you left out part of the solution space: - simply don't include this poorly-designed functionality in NetBSD. Thor
Re: very bad behavior on overquota writes
On Thu, Nov 22, 2012 at 12:46:54PM +0100, Manuel Bouyer wrote:
> Index: uvm/uvm_vnode.c
> ===
> RCS file: /cvsroot/src/sys/uvm/uvm_vnode.c,v
> retrieving revision 1.97.8.1
> diff -u -p -u -r1.97.8.1 uvm_vnode.c
> --- uvm/uvm_vnode.c 11 Jun 2012 21:25:02 - 1.97.8.1
> +++ uvm/uvm_vnode.c 22 Nov 2012 11:31:25 -
> @@ -351,7 +351,7 @@ uvm_vnp_setsize(struct vnode *vp, voff_t
> KASSERT(oldsize != VSIZENOTSET || pgend > oldsize);
>
> if (oldsize > pgend) {
> - (void) uvn_put(uobj, pgend, 0, PGO_FREE | PGO_SYNCIO);
> + (void) uvn_put(uobj, pgend, oldsize, PGO_FREE | PGO_SYNCIO);
> mutex_enter(uobj->vmobjlock);
> }
> vp->v_size = vp->v_writesize = newsize;
I found that VOP_PUTPAGES wants page-aligned boundaries, so this needs to be
changed to:
+ (void) uvn_put(uobj, pgend, round_page(oldsize),
+ PGO_FREE | PGO_SYNCIO);
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
