FW: poor permissions on ssh binary

Loomis, Rip GILBERT.R.LOOMIS at saic.com
Wed Jun 20 00:14:17 EST 2001

-----Original Message-----
From: Loomis, Rip 
Sent: Tuesday, 19 June, 2001 09:10
To: 'geoff at raye.com'
Subject: RE: poor permissions on ssh binary

You stated that you consider it "a poor choice
of permissions" to install the ssh binary as
mode 0711.  Since it will run perfectly with
even more restrictive permissions (we typically
install it mode 0511 here), what is your
objection to those permissions?  You state that
0755 would "make more sense" than 0711...but
you haven't provided a convincing argument as
to what the problem is.

As a general rule when locking down a system, we
change the "ugo" permissions on all security-critical
executables (including all SetUID/SetGID programs)
to mode 511, and although there's some additional
administrative burden it has also minimized
exposure to certain vulnerabilities in the past. 

Here's my list of pro's and con's:
Disadvantages of 0711 perms:
1.  Doesn't allow non-privileged users to copy
	the installed binaries to other systems
	or locations (which could be useful to
	that user).  

Advantages of 0711 perms:
1.  Doesn't allow non-privileged users to read
	the installed binaries (which could
	be used to run strings against them to
	find out compiled options, etc.)
2.  Doesn't allow non-privileged users to copy
	the installed binaries to other systems
	or locations (the copied binaries could
	then *potentially* be directly modified
	or trojaned--but this is highly unlikely
	in today's world).
3.  System administrators can still copy the
	installed binaries to other systems or

Note that I don't think that those advantages
are particularly amazing, and in fact any
bad guy who wants to do something evil with
OpenSSH would just start with the source.
However, the binaries run just fine with the
current permissions, and there's this important
security concept called Least Privilege--which
I'll explain in this case as "one shouldn't go
around giving users or processes powers that
they don't absolutely require, because one can't
always predict future bugs and exposures."

The bottom line is that I can't come up with
a convincing reason why the permissions should
change.  If you've got one, then please send
it to the list and the core development team
can decide what to do.  Any organization that wants
less restrictive permissions should feel free
to install it that way...but I don't feel that
the current default is broken.  

Rip Loomis
Senior Systems Security Engineer, SAIC CIST
Brainbench MVP for Internet Security
http://www.brainbench.com  [Transcript 1923411]

-----Original Message-----
From: Geoff Raye [mailto:raye at meow.raye.com]
Sent: Monday, 18 June, 2001 18:52
To: openssh at openssh.com
Subject: poor permissions on ssh binary

I just installed portable openssh 2.9p2, but the issue I have shouldn't
be unique to the portable version.

I built with
% ../configure --prefix=/usr/local/encap/openssh-2.9p2
--sysconfdir=/etc --with-cflags=-O2 --with-tcp-wrappers
--with-ssl-dir=/usr/local --with-md5-passwords --disable-suid-ssh

When it came time to make install, this command was executed:
/usr/local/bin/install -c -m 0711 -s ssh

I consider it a poor choice of permissions to make ssh be 0711, and I
believe that configure.in should be changed on line 1624:
would make more sense than

For that matter, I believe that the suid root binary has no compelling
reason not to be world-readable, either, but I don't know whether there
have been past security implications of this which would warrant keeping
the file unreadable and not copyable.

In any event, keeping non-suid ssh binaries 0711 is a choice which goes
back to the original f-secure/commercial/tatu SSH.

Thank you for your consideration.

Geoff Raye

Geoff Raye       \ All irregularities will be handled by the forces
geoff at raye.com    \ controlling each dimension.  Transuranic heavy
                   \ elements may not be used where there is life.

More information about the openssh-unix-dev mailing list