Re: fexecve, round 3
On Sun, Nov 25, 2012 at 10:58:01PM -0500, Thor Lancelot Simon wrote: 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. Then please point me to the message that addresses the objection above. I did not meant to shortcut your contribution to the discussion, I just must have missed it in the long threads, 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 The idea is to try summing up the previous discussions. I may sometimes fail at this task, but the intent is to make the rthing more readable. -- Emmanuel Dreyfus m...@netbsd.org
Re: fexecve, round 3
Does anyone know of a setup that uses a process outside of a chroot doing descriptor passing to a chrooted process? I wonder if we should disallow that completely (i.e. fail the anxiliary data send if sender and recipient have different p_cwdi-cwdi_rdir)? Martin
Re: fexecve, round 3
On Mon, Nov 26, 2012 at 10:18:42AM +0100, Martin Husemann wrote: Does anyone know of a setup that uses a process outside of a chroot doing descriptor passing to a chrooted process? Yes. I mentioned some earlier in this discussion, before the thread jumps. I don't have time to write it up again now. I'll try to find the time later today. Thor
Re: fexecve, round 3
On Mon, Nov 26, 2012 at 10:18:42AM +0100, Martin Husemann wrote: Does anyone know of a setup that uses a process outside of a chroot doing descriptor passing to a chrooted process? Yes. I can point to the same example as Thor has described, but I think that it is easy to cook up numerous useful examples. I wonder if we should disallow that completely (i.e. fail the anxiliary data send if sender and recipient have different p_cwdi-cwdi_rdir)? This idea of failing the ancillary data transmission seems unnecessarily inflexible to me. I think that if process A has a send descriptors privilege, and process B has a receive descriptors privilege, and there is some communications channel from A to B, then A should be able to send a descriptor to B regardless of the origin or properties of that descriptor. B's privileges may not be sufficient to use certain methods of the descriptor---for example, to fexecve() the descriptor---but I think that is ok, because B's entire purpose may be to send the descriptor to a third process that can use the descriptor. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
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: fexecve, round 3
In article 20121125152520.ga17...@panix.com, Thor Lancelot Simon t...@panix.com 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
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
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
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
David Laight da...@l8s.co.uk 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 Mon, Nov 26, 2012 at 03:22:42AM +0100, Emmanuel Dreyfus wrote: David Laight da...@l8s.co.uk 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
