--- Begin Message ---
Package: openssh-server
Version: 1:6.7p1-3
Severity: wishlist
Hello,
If you add the option ProtectSystem=yes to the service file, then the
daemon will not have the ability to write to /usr.
There is no reason why it needs to write there, so enabling this
option should not cause any problems.
This option is one of the systemd security features for systemd
service files that was detailed in a talk[0] given by Lennart which
details various security features you can enable in your package's
service files.
micah
[0] http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openssh-server depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.54
ii dpkg 1.17.22
ii init-system-helpers 1.22
ii libc6 2.19-13
ii libcomerr2 1.42.12-1
ii libgssapi-krb5-2 1.12.1+dfsg-15
ii libkrb5-3 1.12.1+dfsg-15
ii libpam-modules 1.1.8-3.1
ii libpam-runtime 1.1.8-3.1
ii libpam0g 1.1.8-3.1
ii libselinux1 2.3-2
ii libssl1.0.0 1.0.1j-1
ii libwrap0 7.6.q-25
ii lsb-base 4.1+Debian13+nmu1
ii openssh-client 1:6.7p1-3
ii openssh-sftp-server 1:6.7p1-3
ii procps 2:3.3.9-8
ii zlib1g 1:1.2.8.dfsg-2+b1
Versions of packages openssh-server recommends:
ii ncurses-term 5.9+20140913-1
ii xauth 1:1.0.9-1
Versions of packages openssh-server suggests:
pn molly-guard <none>
ii monkeysphere 0.37-2
pn rssh <none>
ii ssh-askpass 1:1.2.4.1-9
ii ssh-askpass-gnome [ssh-askpass] 1:6.7p1-3
pn ufw <none>
-- debconf information excluded
--- End Message ---
--- Begin Message ---
Control: tag 771625 wontfix
On Sun, Nov 30, 2014 at 11:37:59PM -0500, micah wrote:
> Russ Allbery <rra@debian.org> writes:
> > Micah Anderson <micah@debian.org> writes:
> >> If you add the option ProtectSystem=yes to the service file, then the
> >> daemon will not have the ability to write to /usr.
> >
> > How does this interact with the OpenSSH daemon, which spawns user shells?
> > I was (blindly) assuming that these security settings would be inherited
> > by all child processes of the spawned process, so you'd end up with shells
> > that also had read-only /usr, possibly interfering with later sudo, su, or
> > other similar operations.
>
> That is a good point. Unless I did something wrong, I just set this in
> my system's ssh service file, like this:
[...]
> # systemctl daemon-reload
> # systemctl reload ssh
That doesn't actually restart sshd; it just SIGHUPs it, so the changes
to the service file don't take effect. If you do "systemctl restart
ssh" instead, as I did in my test just now, you'll get:
$ sudo touch /usr/foo
touch: cannot touch ‘/usr/foo’: Read-only file system
The ProtectSystem (etc.) mounts aren't per-cgroup, but are inherited by
child processes. Indeed it's hard to see how it would be implemented
otherwise given the filesystem-namespace-based design.
I'm therefore closing this bug as it can't be implemented without making
it impossible to administer the system over ssh. Sorry.
--
Colin Watson [cjwatson@debian.org]
--- End Message ---