Re: Wrong rights for ELF interpreters
On 10/20/13 21:54, Theo de Raadt wrote: Indeed, the interpreter is not passed to execve. That's why I used 'get executed' instead of 'are executed' though the difference might not be clear. The kernel loads the interpreter, and the code of that interpreter gets executed. So, actually, it plays as an executable. And as long as code gets executed from it, it should have +x rights. Shouldn't it? Absolutely not, because then someone can try to run execve on it. Maybe I'm missing something. I don't get what's wrong with running execve on it. In all cases, someone can load it through another executable. If I have an interpreter that I chmod as exec-only, I want this interpreter to be world-loadable without thereby letting other users copy it. The same for a library. You are not thinking clearly. I've just given a glance to FreeBSD and NetBSD. They both check exec rights, not read rights. So it looks like I'm not the only one who does not think clearly...
Re: Wrong rights for ELF interpreters
I don't get what's wrong with running execve on it. In all cases, someone can load it through another executable. Using ld.so does not imply execve'ing it. If I have an interpreter that I chmod as exec-only, I want this interpreter to be world-loadable without thereby letting other users copy it. The same for a library. It is loadable. Because it is readable.
Re: Wrong rights for ELF interpreters
Le 21/10/2013 09:38, Theo de Raadt a écrit : I don't get what's wrong with running execve on it. In all cases, someone can load it through another executable. Using ld.so does not imply execve'ing it. If I have an interpreter that I chmod as exec-only, I want this interpreter to be world-loadable without thereby letting other users copy it. The same for a library. It is loadable. Because it is readable. I said exec-only, so no it is not readable and not loadable. My point was that, actually, it should be loadable. But after sleeping a bit, I figured out that there may indeed be some issues with some libraries. To me it looks weird. I'm gonna investigate a bit, and if I have an objection I'll send it here. Until then, sorry for the noise.
Re: Wrong rights for ELF interpreters
when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this.
Re: Wrong rights for ELF interpreters
Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why?
Re: Wrong rights for ELF interpreters
Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? VEXEC is used in other cases to insist on a filesystem permission, for instance, when supplying a path for execve(). The interpreter is not a path supplied to execve.
Re: Wrong rights for ELF interpreters
On Sun, Oct 20, 2013 at 18:00, Maxime Villard wrote: It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? How is loading the interpreter different than loading a shared library? Libraries are executed, too.
Re: Wrong rights for ELF interpreters
Le 20/10/2013 18:05, Theo de Raadt a écrit : Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? VEXEC is used in other cases to insist on a filesystem permission, for instance, when supplying a path for execve(). The interpreter is not a path supplied to execve. Indeed, the interpreter is not passed to execve. That's why I used 'get executed' instead of 'are executed' though the difference might not be clear. The kernel loads the interpreter, and the code of that interpreter gets executed. So, actually, it plays as an executable. And as long as code gets executed from it, it should have +x rights. Shouldn't it?
Re: Wrong rights for ELF interpreters
It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? How is loading the interpreter different than loading a shared library? Libraries are executed, too. good lord. chmod a+x /usr/lib/lib*.so.*.* It is silly.
Re: Wrong rights for ELF interpreters
Le 20/10/2013 18:05, Theo de Raadt a écrit : Le 20/10/2013 16:53, Theo de Raadt a écrit : when the kernel loads an ELF binary, it will also load its interpreter. The kernel checks the rights of the interpreter, that way: if ((error = VOP_ACCESS(vp, VREAD, p-p_ucred, p)) != 0) goto bad1; It should check with VEXEC instead of VREAD. Interpreters get executed, so they have to be executable; a read-only interpreter shouldn't be loaded by the kernel. I am not sure I agree on this. Why? VEXEC is used in other cases to insist on a filesystem permission, for instance, when supplying a path for execve(). The interpreter is not a path supplied to execve. Indeed, the interpreter is not passed to execve. That's why I used 'get executed' instead of 'are executed' though the difference might not be clear. The kernel loads the interpreter, and the code of that interpreter gets executed. So, actually, it plays as an executable. And as long as code gets executed from it, it should have +x rights. Shouldn't it? Absolutely not, because then someone can try to run execve on it. You are not thinking clearly.
