Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
Hi Dave, On Tue, 18 Mar 2014 13:29:36 -0400 Dave Reisner d...@falconindy.com wrote: [...] Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... True for the interpreted code. And compiled code. The linker is your ELF interpreter. Sorry if this is off-topic, but how do you that? With /lib/ld-2.19.so /path/to/executable? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
[Sorry, forgot to CC the mailing list] Hi Lennart, On Tue, 18 Mar 2014 02:33:50 +0100 Lennart Poettering lenn...@poettering.net wrote: On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather permissive, hardcoded mount options (or at least I couldn't find a documented way of changing them). Specifically, a user is allowed to execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's ability to constrain users, e.g. by mounting /home as noexec (I have seen this done in some environments). Is there a need to allow execution from $XDG_RUNTIME_DIR? And how should one configure its mount options? Yes, this is hardcoded in 211, that's true. We could make this configurable but I am not really convinced that we really want that? I agree that a complete, fstab-like configuration may be too much. I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by the standards of the operating system. More specifically, ... proper permissions ... must be supported. I'd read that as if the x bit should do what it is supposed to do. So, in order to stay compatible with the spec allowing to mount it with noexec sounds undesirable. Well, regardless of what the XDG specification says, the fact is that currently each user has 2 /home's: one under the admin control, another -- not. Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR upon login, but this is hacking around the init system... What about making XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate partition and fall back to the current default otherwise? Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... True for the interpreted code. However regarding other places, if an admin cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also constrained (I am not saying that this should be the default, just configurable). Thanks, Leonid. Note that setting noexec on an fs means you cannot maps its files PROT_EXEC anymore, which breaks a number of things. In the past people attempted to mount /dev/shm as noexec, and dosemu broke because it made use of this. Then people wanted to mount /dev as noexec, which broke X11 which wanted to map some device nodes PROT_EXEC. Given that we consider XDG_RUNTIME_DIR as a private version of /dev/shm among other things it really sounds wrong to break this right from the start. So, I am not really convinced I must say... Lennart -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
On Mar 18, 2014 12:59 PM, Leonid Isaev lis...@umail.iu.edu wrote: [Sorry, forgot to CC the mailing list] Hi Lennart, On Tue, 18 Mar 2014 02:33:50 +0100 Lennart Poettering lenn...@poettering.net wrote: On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather permissive, hardcoded mount options (or at least I couldn't find a documented way of changing them). Specifically, a user is allowed to execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's ability to constrain users, e.g. by mounting /home as noexec (I have seen this done in some environments). Is there a need to allow execution from $XDG_RUNTIME_DIR? And how should one configure its mount options? Yes, this is hardcoded in 211, that's true. We could make this configurable but I am not really convinced that we really want that? I agree that a complete, fstab-like configuration may be too much. I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by the standards of the operating system. More specifically, ... proper permissions ... must be supported. I'd read that as if the x bit should do what it is supposed to do. So, in order to stay compatible with the spec allowing to mount it with noexec sounds undesirable. Well, regardless of what the XDG specification says, the fact is that currently each user has 2 /home's: one under the admin control, another -- not. Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR upon login, but this is hacking around the init system... What about making XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate partition and fall back to the current default otherwise? Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... True for the interpreted code. And compiled code. The linker is your ELF interpreter. However regarding other places, if an admin cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also constrained (I am not saying that this should be the default, just configurable). Thanks, Leonid. Note that setting noexec on an fs means you cannot maps its files PROT_EXEC anymore, which breaks a number of things. In the past people attempted to mount /dev/shm as noexec, and dosemu broke because it made use of this. Then people wanted to mount /dev as noexec, which broke X11 which wanted to map some device nodes PROT_EXEC. Given that we consider XDG_RUNTIME_DIR as a private version of /dev/shm among other things it really sounds wrong to break this right from the start. So, I am not really convinced I must say... Lennart -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
On Tue, 18.03.14 12:59, Leonid Isaev (lis...@umail.iu.edu) wrote: I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by the standards of the operating system. More specifically, ... proper permissions ... must be supported. I'd read that as if the x bit should do what it is supposed to do. So, in order to stay compatible with the spec allowing to mount it with noexec sounds undesirable. Well, regardless of what the XDG specification says, the fact is that currently each user has 2 /home's: one under the admin control, another -- not. Well, the XDG runtime dir is not really a home directory. It has very clear semantics and lifecycles, and they are quite different from /home. Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR upon login, but this is hacking around the init system... What about making XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate partition and fall back to the current default otherwise? So when we standardized XDG_RUNTIME_DIR we did so because of the broken semantics of /home, where there's no guarantee that file locking, mmapping, unix sockets, fifos, exec, ... would work correctly. Hence for local runtime stuff we came up with XDG_RUNTIME_DIR, which should clean all this up, have a clear lifecycle and be the much better place for doing all these things. It sounds really backwards to me to weaken this clear definition by making some of the features completely optional again. I mean, it's fine if people locally override how things are set up, and willingly break what is written in the spec, but I am pretty sure we shouldn't push them to do that by making this too easy to change. Or with other words: what you want to do there is explicitly what you say you don't want to do: hacking around the init system! So, if you want to do that, then go ahead, but I really doubt we should support anything like this with an easy option upstream. Sorry. Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... True for the interpreted code. However regarding other places, if an admin cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also constrained (I am not saying that this should be the default, just configurable). Well, the ELF interpretor stuff means noexec is pretty much entirely useless. I only see drawbacks of this I must say. I really don't see the benefit of adding a config option for this. Sorry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
On Mar 18, 2014 8:19 PM, Lennart Poettering lenn...@poettering.net wrote: … Well, the ELF interpretor stuff means noexec is pretty much entirely useless. If by this you mean running '/lib/ld-linux.so.2' directly, that does not work with noexec anymore, due to the aforementioned mmap restriction AFAIK: /mnt/test: error while loading shared libraries: /mnt/test: failed to map segment from shared object: Operation not permitted ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mount options for $XDG_RUNTIME_DIR
Hi, Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather permissive, hardcoded mount options (or at least I couldn't find a documented way of changing them). Specifically, a user is allowed to execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's ability to constrain users, e.g. by mounting /home as noexec (I have seen this done in some environments). Is there a need to allow execution from $XDG_RUNTIME_DIR? And how should one configure its mount options? Thanks, -- Leonid Isaev GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR
On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather permissive, hardcoded mount options (or at least I couldn't find a documented way of changing them). Specifically, a user is allowed to execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's ability to constrain users, e.g. by mounting /home as noexec (I have seen this done in some environments). Is there a need to allow execution from $XDG_RUNTIME_DIR? And how should one configure its mount options? Yes, this is hardcoded in 211, that's true. We could make this configurable but I am not really convinced that we really want that? I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by the standards of the operating system. More specifically, ... proper permissions ... must be supported. I'd read that as if the x bit should do what it is supposed to do. So, in order to stay compatible with the spec allowing to mount it with noexec sounds undesirable. Moreover noexec is mostly snake-oil, isn't it? You can invoke the executables with an interpreter still, and you can copy the files elsewhere... Note that setting noexec on an fs means you cannot maps its files PROT_EXEC anymore, which breaks a number of things. In the past people attempted to mount /dev/shm as noexec, and dosemu broke because it made use of this. Then people wanted to mount /dev as noexec, which broke X11 which wanted to map some device nodes PROT_EXEC. Given that we consider XDG_RUNTIME_DIR as a private version of /dev/shm among other things it really sounds wrong to break this right from the start. So, I am not really convinced I must say... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
