On Thu, Nov 15, 2012 at 11:12:09AM +, Emmanuel Dreyfus wrote:
> Hi
>
> Here is a patch that implements fexecve(2) for review:
> http://ftp.espci.fr/shadow/manu/fexecve.patch
This strikes me as profoundly dangerous. Among other things, it
means you can't allow any program running in a chroot
Date: Thu, 15 Nov 2012 11:03:15 -0500
From: Thor Lancelot Simon
On Thu, Nov 15, 2012 at 11:12:09AM +, Emmanuel Dreyfus wrote:
> Hi
>
> Here is a patch that implements fexecve(2) for review:
> http://ftp.espci.fr/shadow/manu/fexecve.patch
This strikes me as profoundly
On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> This strikes me as profoundly dangerous. Among other things, it
> means you can't allow any program running in a chroot to receive
> unix-domain messages any more since they might get passed a file
> descriptor to code they sho
On Thu, Nov 15, 2012 at 05:23:04PM +, Emmanuel Dreyfus wrote:
> On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> > This strikes me as profoundly dangerous. Among other things, it
> > means you can't allow any program running in a chroot to receive
> > unix-domain messages
>> Here is a patch that implements fexecve(2) for review:
> This strikes me as profoundly dangerous. Among other things, it
> means you can't allow any program running in a chroot to receive
> unix-domain messages any more since they might get passed a file
> descriptor to code they should not be
On Thu, Nov 15, 2012 at 01:16:27PM -0500, Mouse wrote:
> >> Here is a patch that implements fexecve(2) for review:
>
> > This strikes me as profoundly dangerous. Among other things, it
> > means you can't allow any program running in a chroot to receive
> > unix-domain messages any more since the
> All of a sudden, the very presence of those sockets means not just
> that a component A running in chroot Ca, with uid Ua, can pass _data_
> to a component B running in chroot Cb, with uid Ub -- which was part
> of the design -- but that it can enable B to run new code that was
> formerly not ava
On Thu, Nov 15, 2012 at 01:50:54PM -0500, Mouse wrote:
> > All of a sudden, the very presence of those sockets means not just
> > that a component A running in chroot Ca, with uid Ua, can pass _data_
> > to a component B running in chroot Cb, with uid Ub -- which was part
> > of the design -- but t
>> It always could, just not with exec()-family calls. Did you read
>> the points you didn't quote about script interpreters and VMs?
> What script interpreters? What VMs? Why would I include one in such
> an environment?
Why would you include a call to fexecve()? You need cooperation from
the
Thor Lancelot Simon wrote:
> The point is, this is interesting functionality that makes something
> new possible that is potentially useful from a security point of view,
> but the new thing that's possible also breaks assumptions that existing
> code may rely on to get security guarantees it wan
On Nov 15, 2012, at 11:20 AM, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon wrote:
>
>> The point is, this is interesting functionality that makes something
>> new possible that is potentially useful from a security point of view,
>> but the new thing that's possible also breaks assumptions tha
On Thu, 15 Nov 2012 11:03:15 -0500
Thor Lancelot Simon wrote:
> This strikes me as profoundly dangerous. Among other things, it
> means you can't allow any program running in a chroot to receive
> unix-domain messages any more since they might get passed a file
> descriptor to code they should n
On Thu, Nov 15, 2012 at 08:20:30PM +0100, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon wrote:
>
> > The point is, this is interesting functionality that makes something
> > new possible that is potentially useful from a security point of view,
> > but the new thing that's possible also breaks as
On Thu, Nov 15, 2012 at 06:35:48PM +, Julian Yon wrote:
>
> As you mention Linux, their man page for fexecve states ?The file
> descriptor fd must be opened read-only, and the caller must have
> permission to execute the file that it refers to.? It sounds like that
> might be what you're missi
On Thu, Nov 15, 2012 at 08:20:30PM +0100, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon wrote:
>
> > The point is, this is interesting functionality that makes something
> > new possible that is potentially useful from a security point of view,
> > but the new thing that's possible also breaks as
On Thu, 15 Nov 2012 16:02:50 -0500
Thor Lancelot Simon wrote:
> Look at that rationale carefully and I think you will see the race
> condition that it does not eliminate. Talk about a "solution looking
> for a problem"!
Indeed I do. Fair point.
Julian
--
3072D/F3A66B3A Julian Yon (2012 Gener
On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> > Here is a patch that implements fexecve(2) for review:
> > http://ftp.espci.fr/shadow/manu/fexecve.patch
>
> This strikes me as profoundly dangerous. Among other things, it
> means you can't allow any program running in
Unfortunately I'm having a hell of a day. I can't respond to the
message below in full -- yet. But just to clear up a few nits:
On Thu, Nov 15, 2012 at 09:46:13PM +, David Holland wrote:
> On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> > > Here is a patch that implem
On Thu, Nov 15, 2012 at 09:46:13PM +, David Holland wrote:
> On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> > > Here is a patch that implements fexecve(2) for review:
> > > http://ftp.espci.fr/shadow/manu/fexecve.patch
> >
> > This strikes me as profoundly dangerous
On Thu, Nov 15, 2012 at 04:02:50PM -0500, Thor Lancelot Simon wrote:
> On Thu, Nov 15, 2012 at 06:35:48PM +, Julian Yon wrote:
> >
> > As you mention Linux, their man page for fexecve states ?The file
> > descriptor fd must be opened read-only, and the caller must have
> > permission to execut
On Thu, Nov 15, 2012 at 05:18:04PM -0600, Eric Haszlakiewicz wrote:
>
> Well setuid executables seem like a special case, but other than that, I
> think I can probably manage to execute something without an exec call.
> In fact I know I can, just by linking against any dynamic library and
> callin
On Thu, Nov 15, 2012 at 04:53:26PM -0500, Thor Lancelot Simon wrote:
> > > > Here is a patch that implements fexecve(2) for review:
> > > > http://ftp.espci.fr/shadow/manu/fexecve.patch
> > >
> > > This strikes me as profoundly dangerous. Among other things, it
> > > means you can't all
On Thu, Nov 15, 2012 at 04:57:24PM -0500, Thor Lancelot Simon wrote:
> On Thu, Nov 15, 2012 at 09:46:13PM +, David Holland wrote:
> > On Thu, Nov 15, 2012 at 11:03:15AM -0500, Thor Lancelot Simon wrote:
> > > > Here is a patch that implements fexecve(2) for review:
> > > > http://ftp.espci.fr
> The problem is that there is a great deal of existing code in the
> world which receives file descriptors and which is not designed with
> the possibility that they might then be used to exec.
Then those programs won't be calling fexecve() at all, with any
descriptor, so how does it make the sli
On Thu, Nov 15, 2012 at 10:36:50PM -0500, Mouse wrote:
> > The problem is that there is a great deal of existing code in the
> > world which receives file descriptors and which is not designed with
> > the possibility that they might then be used to exec.
>
> Then those programs won't be calling f
On Thu, Nov 15, 2012 at 10:14:18PM +0100, Joerg Sonnenberger wrote:
> On Thu, Nov 15, 2012 at 08:20:30PM +0100, Emmanuel Dreyfus wrote:
> > Thor Lancelot Simon wrote:
> >
> > > The point is, this is interesting functionality that makes something
> > > new possible that is potentially useful from
On Thu, Nov 15, 2012 at 04:02:50PM -0500, Thor Lancelot Simon wrote:
>
> > From the spec: ?The purpose of the fexecve() function is to enable
> > executing a file which has been verified to be the intended file. It is
> > possible to actively check the file by reading from the file descriptor
> >
On Thu, Nov 15, 2012 at 11:58:59PM -0500, Thor Lancelot Simon wrote:
> > > The problem is that there is a great deal of existing code in the
> > > world which receives file descriptors and which is not designed with
> > > the possibility that they might then be used to exec.
> >
> > Then thos
On Fri, 16 Nov 2012 09:14:14 +
David Holland wrote:
> Well, no. You have to first receive a new file descriptor from
> somewhere, either on an existing socket (requires owning the other
> end) or by opening a new one (not much use in a chroot). Only then you
> can overwrite those ints with th
On Fri, 16 Nov 2012 08:43:20 +
David Laight wrote:
> On Thu, Nov 15, 2012 at 04:02:50PM -0500, Thor Lancelot Simon wrote:
> >
> > Look at that rationale carefully and I think you will see the race
> > condition that it does not eliminate. Talk about a "solution
> > looking for a problem"!
>
On Fri, 16 Nov 2012 08:34:29 +
David Laight 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 t
On Fri, Nov 16, 2012 at 09:14:14AM +, David Holland wrote:
> On Thu, Nov 15, 2012 at 11:58:59PM -0500, Thor Lancelot Simon wrote:
>
> Well, no. You have to first receive a new file descriptor from
> somewhere, either on an existing socket (requires owning the other
> end) or by opening a new o
On Fri, Nov 16, 2012 at 12:35:46PM +, Julian Yon wrote:
> > Meanwhile, if you can own the other end to the point where you can
> > open an executable file containing code you supplied and pass it down
> > an existing socket connection, you've already done arbitrary code
> > execution. If th
On Fri, Nov 16, 2012 at 09:13:13AM -0500, Thor Lancelot Simon wrote:
> On Fri, Nov 16, 2012 at 09:14:14AM +, David Holland wrote:
> > On Thu, Nov 15, 2012 at 11:58:59PM -0500, Thor Lancelot Simon wrote:
> >
> > Well, no. You have to first receive a new file descriptor from
> > somewhere,
On Thu, Nov 15, 2012 at 07:39:03PM -0500, Thor Lancelot Simon wrote:
> On Thu, Nov 15, 2012 at 05:18:04PM -0600, Eric Haszlakiewicz wrote:
> >
> > Well setuid executables seem like a special case, but other than that, I
> > think I can probably manage to execute something without an exec call.
> >
On Fri, Nov 16, 2012 at 11:31:20AM -0600, Eric Haszlakiewicz wrote:
> On Thu, Nov 15, 2012 at 07:39:03PM -0500, Thor Lancelot Simon wrote:
> > On Thu, Nov 15, 2012 at 05:18:04PM -0600, Eric Haszlakiewicz wrote:
> > >
> > > Well setuid executables seem like a special case, but other than that, I
>
On Nov 16, 2012, at 9:50 AM, Thor Lancelot Simon wrote:
> On Fri, Nov 16, 2012 at 11:31:20AM -0600, Eric Haszlakiewicz wrote:
>> On Thu, Nov 15, 2012 at 07:39:03PM -0500, Thor Lancelot Simon wrote:
>>> On Thu, Nov 15, 2012 at 05:18:04PM -0600, Eric Haszlakiewicz wrote:
Well setuid exec
Julian Yon wrote:
> The spec only requires that the file only needs to be open for reading.
That is not completely clear to me. open(2) and openat(2) get a O_EXEC
flag, but I did not found other reference of it: fexecve(2)
specification does explicitely require a fd open with O_EXEC.
We could
Thor Lancelot Simon wrote:
> What is this "opened for execution"? I don't see it in the open(2)
> manual page
Look for O_EXEC here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/openat.html
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
Emmanuel Dreyfus wrote:
> > The spec only requires that the file only needs to be open for reading.
>
> That is not completely clear to me. open(2) and openat(2) get a O_EXEC
> flag, but I did not found other reference of it: fexecve(2)
> specification does explicitely require a fd open with O_E
On Fri, Nov 16, 2012 at 08:02:16PM +0100, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon wrote:
>
> > What is this "opened for execution"? I don't see it in the open(2)
> > manual page
>
> Look for O_EXEC here:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/openat.html
Oof, they g
On Fri, 16 Nov 2012 20:08:45 +0100
m...@netbsd.org (Emmanuel Dreyfus) wrote:
> Emmanuel Dreyfus wrote:
>
> > > The spec only requires that the file only needs to be open for
> > > reading.
> >
> > That is not completely clear to me. open(2) and openat(2) get a
> > O_EXEC flag, but I did not fou
> However as has been pointed out ([...]), fexecve doesn't actually
> solve the problem it's intended to solve.
I think it probably does, but that is narrower than the problem you're
probably thinking of.
What I got from the description is that fexecve is intended to solve
file substitution attac
On Fri, 16 Nov 2012 15:46:00 -0500 (EST)
Mouse wrote:
> Nobody has quite come right out and said what the race supposedly
> remaining with fexecve is, or at least not that I've seen; the only
> one I've been able to think of is a TOCTOU race with someone
> overwriting the file between check and e
On Thu 15 Nov 2012 at 20:18:56 -0600, David Young wrote:
> Label a file descriptor with the root that was in effect when it was created
> by, say, open(2). The effective root will never change over the
> lifetime of that descriptor.
As devil's advocate:
How does this relate to the proposed pivot_
On Sat, Nov 17, 2012 at 12:16:49AM +0100, Rhialto wrote:
> On Thu 15 Nov 2012 at 20:18:56 -0600, David Young wrote:
> > Also, enforcing access along "effective roots" lines may be inflexible
> > or unwieldy, maybe a more abstract notion of "process coalition" is
> > better. Let each new root have
On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote:
> On Fri, 16 Nov 2012 08:34:29 +
> David Laight 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
> On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote:
> > On Fri, 16 Nov 2012 08:34:29 +
> > David Laight 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
On Sat, 17 Nov 2012 21:45:02 +
David Laight 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
On Sun, Nov 18, 2012 at 07:27:27PM +, Julian Yon wrote:
> On Sat, 17 Nov 2012 21:45:02 +
> David Laight 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
On Sun, 18 Nov 2012 14:31:29 -0500
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 wrote:
> >
> > > You don't need the executable image inside the chroot.
> >
> > I don't believe that's intended to
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 wrote:
>>
>>> On Fri, Nov 16, 2012 at 12:52:30PM +, Julian Yon wrote:
What does this gain over passing a fi
On Sun, 18 Nov 2012 14:08:05 -0800
Matt Thomas 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,
> 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.
I disagree that it's pointless.
You can still check that, for example, it's the same dev/inumber/size
you have recorded in
54 matches
Mail list logo
