Re: [PATCH] fexecve
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 a database of what executables ought to be. Not as good as a full checksum, but certainly a higher bar than just winning a switch-the-symlink race. Also, as someone else pointed out upthread, you can open executables before you chroot, hang onto the fds, and execute them later. fexecve() is also the only way to execute a binary that has no accessible name (and chroots are not the only way that can happen). For example, maybe you've just written into an unlinked file, or maybe it exists in a part of the filesystem namespace that now has something mounted in front of it. (Whether these are good things to be able to do is open to debate, of course.) /~\ 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: [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: [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: [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: [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: [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
Re: [PATCH] fexecve
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 a corresponding new coalition, but perhaps we should be able to create a new coalition without changing root, and change root without changing coalition. That would make yet another process grouping, confusingly (dis)similar to process groups, controlling-terminal groups, sessions, (and am I forgetting more perhaps?) Process groups, controlling-terminal groups, and sessions are not already confusingly dissimilar from each other? Perhaps coalitions could subsume them all: process group, controlling-terminal groups, and sessions could become coalitions of different privileges properties. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
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. David -- David Laight: da...@l8s.co.uk
Re: [PATCH] fexecve
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 t...@panix.com 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 wants. Well, it is standard mandated and we want to be standard compliant. If it is a security hazard, we can have a sysctl to disable the system call. Something like sysctl -w kern.fexecve = 0 and it would return ENOSYS. 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. Oh, and now make $ORIGIN work for dynamic executables and fexec() :-) (Probably not a good idea inside choots! At least you wouldn't want it to work AFTER the initil program load.) David -- David Laight: da...@l8s.co.uk
Re: [PATCH] fexecve
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 and be sure that the file is not exchanged for another between the reading and the execution.? ...which seems a reasonable enough thing to want to do. 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! You could create a temporary file, unlink it, copy the executable into the new file, verify the the contents, and then exec the unlinked temporary file. Better add an open mode that hard disables writes (as used on many systems for executables anyway), open the file with that mode ... David -- David Laight: da...@l8s.co.uk
Re: [PATCH] fexecve
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 those programs won't be calling fexecve() at all, with any descriptor, so how does it make the slightest bit of difference to them what fexecve() does? Providing the fexecve() system call has the potential to turn any vulnerability that lets the attacker overwrite an int (possibly a couple of ints) into a quick path to arbitrary code execution if the attacker's anywhere else on the system with the ability to pass in a file descriptor. No complicated injection of shell code required, no real intricate business of composing a complex exploit out of available return-to-libc vectors; you just have to get fexecve() run once -- just have to corrupt one system call and its arguments -- with a descriptor you passed in. 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 the number of the new fd and trigger fexecve(); otherwise you'll get EBADF, because presumably in a construction like this random file handles that have already been passed around won't have been opened for execution; nor would executing one of them be likely to do anything useful anyway. 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 the other end is a W^X chroot, that's not supposed to be possible; if the other end isn't chrooted you've probably already won. So while this may make some kinds of hack propagation somewhat easier, I'm not at all convinced that it's an instant catastrophe. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
On Fri, 16 Nov 2012 08:43:20 + David Laight da...@l8s.co.uk 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! You could create a temporary file, unlink it, copy the executable into the new file, verify the the contents, and then exec the unlinked temporary file. What you've done here is increase the complexity of the attack (win two races instead of one) but not eliminate it. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
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). Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
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 the other end is a W^X chroot, that's not supposed to be possible; if the other end isn't chrooted you've probably already won. The spec only requires that the file only needs to be open for reading. The calling process needs to have permission to execute the file, but in Thor's scenario the process that opens the FD doesn't. That is clearly broken, then. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
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, 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 the number of the new fd and trigger fexecve(); otherwise you'll get EBADF, because presumably in a construction like this random file handles that have already been passed around won't have been opened for execution; nor would executing one of them be likely to do anything useful anyway. What is this opened for execution? Something that you need to have to make the whole thing not be a horrible disaster, and that I naively assumed would have been defined properly. I guess the people who touted this to the POSIX committee didn't bother to work through even the elementary design considerations. Without some notion of open for execution, open followed by fexecve is not equivalent to plain execve even for a single process, let alone in complicated scenarios involving fd passing or inheritance. Meanwhile [...] Never mind; all that reasoning appears to have based on false assumptions. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
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. In fact I know I can, just by linking against any dynamic library and calling one of the functions in it. You can't load a dynamic library that's on a filesystem mounted noexec. er... so the dynamic linker looks like it tries to mmap the file with execute permissions, and that fails, but what's to prevent me from just reading the file into memory and jumping to that address? I feel like I'm missing something here... eric
Re: [PATCH] fexecve
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 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 calling one of the functions in it. You can't load a dynamic library that's on a filesystem mounted noexec. er... so the dynamic linker looks like it tries to mmap the file with execute permissions, and that fails, but what's to prevent me from just reading the file into memory and jumping to that address? I feel like I'm missing something here... If it's not mapped MAP_EXEC, you can't jump there. If you can, you either have a hardware limitation that makes W^X impossible, or you have a pmap bug.
Re: [PATCH] fexecve
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 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 calling one of the functions in it. You can't load a dynamic library that's on a filesystem mounted noexec. er... so the dynamic linker looks like it tries to mmap the file with execute permissions, and that fails, but what's to prevent me from just reading the file into memory and jumping to that address? I feel like I'm missing something here... If it's not mapped MAP_EXEC, you can't jump there. If you can, you either have a hardware limitation that makes W^X impossible, or you have a pmap bug. Assuming the MMU h/w supports the concept of exec pages. Only recently have some ARM, MIPS, and PowerPC chips added no-execute support.
Re: [PATCH] fexecve
Julian Yon jul...@yon.org.uk 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 have such a limitation, though: it requires real cooperation between two the two processes if the opener needs to use O_EXEC and the executer needs to call fexecve(2) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [PATCH] fexecve
Thor Lancelot Simon t...@panix.com 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
Re: [PATCH] fexecve
Emmanuel Dreyfus m...@netbsd.org 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. Wait, it actually says something: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html --- cut here--- 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. Note that when a file descriptor is opened with O_RDONLY, O_RDWR, or O_WRONLY mode, the file descriptor can be used to read, read and write, or write the file, respectively, even if the mode of the file changes after the file was opened. Using the O_EXEC open mode is different; fexecve() will ignore the mode that was used when the file descriptor was opened and the exec will fail if the mode of the file associated with fd does not grant execute permission to the calling process at the time fexecve() is called. --- cut here--- -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [PATCH] fexecve
On Fri, Nov 16, 2012 at 08:02:16PM +0100, Emmanuel Dreyfus wrote: Thor Lancelot Simon t...@panix.com 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 got it wrong. Open for execute only - deny read/write. What was wanted was Open for execute - allow fexecve. Defined the way they did it, the only reasonable interpretation is that you can call fexecve() on a file descriptor even if it was opened without this flag. Thor
Re: [PATCH] fexecve
On Fri, 16 Nov 2012 20:08:45 +0100 m...@netbsd.org (Emmanuel Dreyfus) wrote: Emmanuel Dreyfus m...@netbsd.org 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. Wait, it actually says something: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html --- cut here--- 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. Note that when a file descriptor is opened with O_RDONLY, O_RDWR, or O_WRONLY mode, the file descriptor can be used to read, read and write, or write the file, respectively, even if the mode of the file changes after the file was opened. Using the O_EXEC open mode is different; fexecve() will ignore the mode that was used when the file descriptor was opened and the exec will fail if the mode of the file associated with fd does not grant execute permission to the calling process at the time fexecve() is called. --- cut here--- Let me interpret that for you: (a) If you have read access to the file, you may open the file for reading, perform whatever operation you were doing (e.g. checksum) then pass it to fexecve. *At this point* execute permission will be checked, and if the calling process has such permission, the file will be executed. i.e. nothing says you have to have execute permission when you first open the file. (b) If you don't have read access, but do have execute permission, you can open the file with O_EXEC; this won't allow you to read the contents but will give you a handle for fexecve. As with case (a), execute permission will be checked at this point for the calling process, even though it was already checked when you opened the file. I'm struggling to think of a sane reason why case (b) would ever apply, but in any case unless I'm missing something, NetBSD doesn't define O_EXEC anyway (nor does Linux). Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
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 attacks, eg via repointing symlinks - a TOCTOU attack based on a name naming one file at check time and a different file at use time. And that, I think, it does solve. 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 execute, and that one fexecve does not solve. (It could be tweaked to solve it, by (for example) making O_EXEC (a) required for fexecve and (b) lock the file against writes in the same way executing it does, the way that's behind ETXTBSY.) It's true fexecve doesn't solve the latter, but the bar _is_ higher; assuming checking involves checking ownership as well as contents, exploiting it requires the ability to overwrite a file owned by whatever user the check is checking for. (If, as is probably the case in many such uses, that user is root, I have trouble seeing _any_ issue here - anyone who can overwrite root-owned files pretty much pwnz0rz the system already.) /~\ 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: [PATCH] fexecve
On Fri, 16 Nov 2012 15:46:00 -0500 (EST) Mouse mo...@rodents-montreal.org 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 execute, and that one fexecve does not solve. Yes, sorry, should have been explicit. That's the ridiculously obvious one. (It could be tweaked to solve it, by (for example) making O_EXEC (a) required for fexecve and (b) lock the file against writes in the same way executing it does, the way that's behind ETXTBSY.) Which would be contrary to the spec anyway, no? If an implementation needs to be non-compliant to be safe, is that better or worse than just not having it at all? O_EXEC seems to exist on FreeBSD but not on OpenBSD or Linux so I doubt there's much code out there that would work unmodified with such an implementation. It's true fexecve doesn't solve the latter, but the bar _is_ higher; assuming checking involves checking ownership as well as contents, exploiting it requires the ability to overwrite a file owned by whatever user the check is checking for. To make this statement, presumably you're also tacitly assuming checking permissions? Doesn't matter who owns it if it's world writeable. (If, as is probably the case in many such uses, that user is root, I have trouble seeing _any_ issue here - anyone who can overwrite root-owned files pretty much pwnz0rz the system already.) Depends whether they can overwrite all root-owned files, or just specific ones (due to some other exploit). Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
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_root system call? [...] Maybe we can weaken fexecve()'s requirement on the effective root of z to root(z) must be reachable from the effective root, but I think that that might be much more complicated. I believe such a check is already done inside the chroot(2) call so it would be doable. [...] 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 a corresponding new coalition, but perhaps we should be able to create a new coalition without changing root, and change root without changing coalition. That would make yet another process grouping, confusingly (dis)similar to process groups, controlling-terminal groups, sessions, (and am I forgetting more perhaps?) Dave -Olaf. -- ___ Olaf 'Rhialto' Seibert -- There's no point being grown-up if you \X/ rhialto/at/xs4all.nl-- can't be childish sometimes. -The 4th Doctor
Re: [PATCH] fexecve
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 to receive unix-domain messages any more since they might get passed a file descriptor to code they should not be able to execute. If there is not some explanation I am missing for why this doesn't basically blow up chroot's security in the very common case where chroot is used to build a W^X environment, I am strongly opposed to ever including this system call in NetBSD. I'm sure the Linux crowd don't care, since they deliberately and proudly punted on actually being able to contain any misbehaving process within a chroot long ago. But that's not us. Thor
Re: [PATCH] fexecve
Date: Thu, 15 Nov 2012 11:03:15 -0500 From: Thor Lancelot Simon t...@panix.com 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 to receive unix-domain messages any more since they might get passed a file descriptor to code they should not be able to execute. Is this an issue only for executables that are setuid/setgid? What does FreeBSD do for fexecve in jails, or in Capsicum?
Re: [PATCH] fexecve
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 should not be able to execute. We can restrict it to VREG vnodes. -- Emmanuel Dreyfus m...@netbsd.org
Re: [PATCH] fexecve
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 any more since they might get passed a file descriptor to code they should not be able to execute. We can restrict it to VREG vnodes. Last I checked, most executable code was accessed by VREG vnodes. Thor
Re: [PATCH] fexecve
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 able to execute. Let me phrase that a bit differently: This gives you the ability to give a chrooted process access to outside-chroot executables in a controlled way. I don't see this as fundamentally any different from using SCM_RIGHTS to give a chrooted executable access to a data file it can't name. Not all executables have their execute bits set, after all; I don't see any fundamental difference between passing a fd to fexecve() and passing a fd to a script for which the chrooted executable happens to contain an interpreter. After all, to do anything with this requires the cooperation of the chrooted process's executable, and if it wants to, heck, it could even include a whole virtual machine and thus execute the executable without ever needing to do anything exec()-family. So, unless I'm missing something, I don't see how this breaks chroots in any way they aren't already broken. /~\ 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: [PATCH] fexecve
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 they might get passed a file descriptor to code they should not be able to execute. Let me phrase that a bit differently: This gives you the ability to give a chrooted process access to outside-chroot executables in a controlled way. Who is the you? It seems to me it's anything outside the chroot that can send to a socket anywhere within it. And that means that you can't really build a TCB inside a chroot, where you can be sure that any storage that is writable is not executable, unless you make it impossible for anything on the outside to write in. That's a major semantic change and not one I think we should make. It will impact real-world systems that use chroot and role accounts to separate application-level privilege. In fact, I built a system like that that's in a fairly widely deployed embedded product, in which file-descriptor passing over sockets is an intentional part of the message-passing protocol that glues the components together. 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 available at all in Cb (because all memory and filesystems available to processes in Cb are either read-only, or executable, but not both). That just sucks. Thor
Re: [PATCH] fexecve
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 available at all in Cb (because all memory and filesystems available to processes in Cb are either read-only, or executable, but not both). It always could, just not with exec()-family calls. Did you read the points you didn't quote about script interpreters and VMs? /~\ 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: [PATCH] fexecve
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 that it can enable B to run new code that was formerly not available at all in Cb (because all memory and filesystems available to processes in Cb are either read-only, or executable, but not both). 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? 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 wants. Despite the fact that if it'd been there since the beginning, this feature might be useful, it is not safe to unleash it now. Thor
Re: [PATCH] fexecve
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 chrooted process either way. /~\ 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: [PATCH] fexecve
Thor Lancelot Simon t...@panix.com 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 wants. Well, it is standard mandated and we want to be standard compliant. If it is a security hazard, we can have a sysctl to disable the system call. Something like sysctl -w kern.fexecve = 0 and it would return ENOSYS. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: [PATCH] fexecve
On Nov 15, 2012, at 11:20 AM, Emmanuel Dreyfus wrote: Thor Lancelot Simon t...@panix.com 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 wants. Well, it is standard mandated and we want to be standard compliant. If it is a security hazard, we can have a sysctl to disable the system call. Something like sysctl -w kern.fexecve = 0 and it would return ENOSYS. Well, I kind of agree that in a chroot, it should not be able to invoke setuid/setgid programs nor programs not owned by root nor a FD opened for write.
Re: [PATCH] fexecve
On Thu, 15 Nov 2012 11:03:15 -0500 Thor Lancelot Simon t...@panix.com 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 not be able to execute. If there is not some explanation I am missing for why this doesn't basically blow up chroot's security in the very common case where chroot is used to build a W^X environment, I am strongly opposed to ever including this system call in NetBSD. I'm sure the Linux crowd don't care, since they deliberately and proudly punted on actually being able to contain any misbehaving process within a chroot long ago. But that's not us. 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 missing? I certainly interpret it to mean that if you can't execve the file, you can't fexecve a FD to it either. 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 and be sure that the file is not exchanged for another between the reading and the execution.” ...which seems a reasonable enough thing to want to do. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
On Thu, Nov 15, 2012 at 08:20:30PM +0100, Emmanuel Dreyfus wrote: Thor Lancelot Simon t...@panix.com 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 wants. Well, it is standard mandated and we want to be standard compliant. If I'm sorry, I consider the above an unsupported assertion about what we want. The SVID is a standard, and we certainly don't want to conform to it... NetBSD's original statement on standards was that we sought conformance with reasonable standards -- and that, specifically, some of the XPG standards (which eventually became the current incarnation of POSIX) were not reasonable. I think there's significant sentiment among the developers that in fact the current POSIX process is producing standards that include some functionality we don't want to implement. That these are standards from which we need to carefully pick and choose, taking the good parts and leaving the bad parts be. In particular, most of the very active participants in that standards process are paid participants working for commercial Linux vendors. They often seem to push half-baked proposals which meet their customers' needs but aren't good general purpose solutions, or in some cases even solutions to problems that actually exist at all. And there are so many of these that some of the really crummy ones slip through, because often only the people pushing them are being paid to spend time on the standards process. Look at the botch with the names of the functions you're currently implementing, or what almost got done last year with filename translation (headed off at the pass partly because a number of NetBSD developers noticed it and vociferously objected). These don't to me bespeak a standard so elegantly or carefully constructed that we should seek mindless conformance with its every whim. Thor
Re: [PATCH] fexecve
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 missing? I certainly interpret it to mean that if you can't execve the file, you can't fexecve a FD to it either. So. Suppose I have a chrooted environment where all accessible filesystems are mounted either ro or noexec. Or for that matter just nosuid. Now someone passes in a file descriptor, from the outside, that is on a filesystem that is not mounted with either of those options. Perhaps, as Matt suggested, one for a setuid executable, yet. Whoops. If this new functionality had been there from the beginning, a reasonable way to protect against it might have been to filter file descriptors when passed so one could not pass _into_ a chroot an fd for a file whose only names were _outside_ it. Though this is actually exceptionally hard to do (consider hard links, and the backwards-namei problem, and...). But that would also eliminate the functionality of passing file descriptors across sockets, into the chroot for purposes *other* than executing them with fexecve, and *that* is functionality that chrooted programs already use! It would in fact break things as commonplace as sshd. My conclusion is that adding this new functionality is unsafe. 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 and be sure that the file is not exchanged for another between the reading and the execution.? ...which seems a reasonable enough thing to want to do. 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! Thor
Re: [PATCH] fexecve
On Thu, Nov 15, 2012 at 08:20:30PM +0100, Emmanuel Dreyfus wrote: Thor Lancelot Simon t...@panix.com 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 wants. Well, it is standard mandated and we want to be standard compliant. If it is a security hazard, we can have a sysctl to disable the system call. Something like sysctl -w kern.fexecve = 0 and it would return ENOSYS. Frankly, I still don't see the point why something would want to use it. Joerg
Re: [PATCH] fexecve
On Thu, 15 Nov 2012 16:02:50 -0500 Thor Lancelot Simon t...@panix.com 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 General Use) pgp.2...@jry.me signature.asc Description: PGP signature
Re: [PATCH] fexecve
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 a chroot to receive unix-domain messages any more since they might get passed a file descriptor to code they should not be able to execute. I have two immediate reactions to this: (1) being able to pass executables to something untrusted in a controlled manner sounds useful, not dangerous; and (2) please define your threat model, because you appear to be assuming the chrooted process is colluding with something outside the chroot, and if that's really true it already effectively has access to everything outside the chroot. Granted we may want to put some controls on fd passing that don't currently exist. If there is not some explanation I am missing for why this doesn't basically blow up chroot's security in the very common case where chroot is used to build a W^X environment, I am strongly opposed to ever including this system call in NetBSD. What mechanism prevents processes from calling mprotect with PROT_EXEC on their own memory? -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
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 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 to receive unix-domain messages any more since they might get passed a file descriptor to code they should not be able to execute. I have two immediate reactions to this: (1) being able to pass executables to something untrusted in a controlled manner sounds useful, not dangerous; and (2) please define your threat model, because you appear to be assuming the chrooted process is colluding with something outside the chroot, and if that's really true it already effectively has access to everything outside the chroot. Are you sure you want to make that assertion with regard to everything? What about two processes in separate chroots? What about a process which can read, but not execute, a file passing an open descriptor for it it to a process running as a UID which has permission to execute it? What about file descriptors for setuid executables, passed to a receiver running in an environment where the entire accessible namespace is mounted nosuid? Granted we may want to put some controls on fd passing that don't currently exist. It's not clear to me what such controls would avoid unexpected behavior both for existing applications which use chroot and fd passing, and also for applications written to use this new interface. What mechanism prevents processes from calling mprotect with PROT_EXEC on their own memory? We have a mechanism quite precisely for that -- see the PaX MPROTECT section in security(8). Thor
Re: [PATCH] fexecve
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. 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 able to execute. I have two immediate reactions to this: (1) being able to pass executables to something untrusted in a controlled manner sounds useful, not dangerous Sorry to cherry-pick one more point for the moment: Considered in a vacuum, I agree with your reaction #1 above. 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. With that history, I don't see a clear way to make this safe (for example by restricting which descriptors can be passed to chrooted processes) without breaking code that assumes it can pass file descriptors without such restrictions. Thor
Re: [PATCH] fexecve
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 execute the file that it refers to.? It sounds like that might be what you're missing? I certainly interpret it to mean that if you can't execve the file, you can't fexecve a FD to it either. So. Suppose I have a chrooted environment where all accessible filesystems are mounted either ro or noexec. Or for that matter just nosuid. Now someone passes in a file descriptor, from the outside, that is on a filesystem that is not mounted with either of those options. Perhaps, as Matt suggested, one for a setuid executable, yet. Whoops. 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 calling one of the functions in it. eric
Re: [PATCH] fexecve
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 calling one of the functions in it. You can't load a dynamic library that's on a filesystem mounted noexec. Thor
Re: [PATCH] fexecve
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 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 able to execute. I have two immediate reactions to this: (1) being able to pass executables to something untrusted in a controlled manner sounds useful, not dangerous; and (2) please define your threat model, because you appear to be assuming the chrooted process is colluding with something outside the chroot, and if that's really true it already effectively has access to everything outside the chroot. Are you sure you want to make that assertion with regard to everything? What about two processes in separate chroots? None of that matters; if the two processes are colluding, either can do anything the other can, simply by asking the other to do it. Which is why you need to define the threat model. What about a process which can read, but not execute, a file passing an open descriptor for it it to a process running as a UID which has permission to execute it? A correct implementation of fexec should not allow that, just as a correct implementation of write does not allow writing to a passed descriptor that came from someone without permission to open it for writing. What about file descriptors for setuid executables, It should probably not be allowed to exec a setuid executable that came from outside your chroot. passed to a receiver running in an environment where the entire accessible namespace is mounted nosuid? This doesn't make any difference. Running a setuid executable in an unexpected and possibly hostile environment is already dangerous. Granted we may want to put some controls on fd passing that don't currently exist. It's not clear to me what such controls would avoid unexpected behavior both for existing applications which use chroot and fd passing, and also for applications written to use this new interface. It's not absolutely clear to me either, but we've spent only a few minutes thinking about it. It seems worth spending a bit of time to see if there's a viable model to be had before dismissing the whole thing as impossible. What mechanism prevents processes from calling mprotect with PROT_EXEC on their own memory? We have a mechanism quite precisely for that -- see the PaX MPROTECT section in security(8). ok, I admit I had been under the impression that PaX didn't actually do anything useful. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] fexecve
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/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 to receive unix-domain messages any more since they might get passed a file descriptor to code they should not be able to execute. I have two immediate reactions to this: (1) being able to pass executables to something untrusted in a controlled manner sounds useful, not dangerous Sorry to cherry-pick one more point for the moment: Considered in a vacuum, I agree with your reaction #1 above. 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. With that history, I don't see a clear way to make this safe (for example by restricting which descriptors can be passed to chrooted processes) without breaking code that assumes it can pass file descriptors without such restrictions. Why restrict what descriptors can be passed? It seems that you could restrict what you can with the descriptors after they are passed. It seems like something like the following can be made to work: 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. Call the root of a descriptor z, root(z). Let fexecve(zfd, ...) compare the root of the kernel file descriptor corresponding to zfd with the effective root and return EPERM if they're unequal. Say that process 1 with effective root pqr opens an executable, fd = open(./setuidprog, ...). Call fd's corresponding kernel descriptor z. Now process 1 passes z to process 2, whose effective root is stu != pqr. Process 2 tries to fexecve() the descriptor, but root(z) != stu so fexecve() returns EPERM. Maybe we can weaken fexecve()'s requirement on the effective root of z to root(z) must be reachable from the effective root, but I think that that might be much more complicated. fexecve() isn't the only call on which you may want to enforce a root(descriptor) == effective root restriction. You may want to enforce it on read(2) and write(2), too. 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 a corresponding new coalition, but perhaps we should be able to create a new coalition without changing root, and change root without changing coalition. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [PATCH] fexecve
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 slightest bit of difference to them what fexecve() does? /~\ 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: [PATCH] fexecve
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 fexecve() at all, with any descriptor, so how does it make the slightest bit of difference to them what fexecve() does? Providing the fexecve() system call has the potential to turn any vulnerability that lets the attacker overwrite an int (possibly a couple of ints) into a quick path to arbitrary code execution if the attacker's anywhere else on the system with the ability to pass in a file descriptor. No complicated injection of shell code required, no real intricate business of composing a complex exploit out of available return-to-libc vectors; you just have to get fexecve() run once -- just have to corrupt one system call and its arguments -- with a descriptor you passed in. Designs that cage things in chroots and message back and forth on unix domain sockets are typically built for privilege separation between components. This system call is tailor-made for cascading compromise through such a system -- you need to really own _one_ component that can send internal messages, and then a wide array of data-driven bugs in other components that would elsewise probably only made denial of service attacks feasible suddenly turn into the ability to feed arbitrary code to those other components and have them jump into it. Not cool.
