On Mon, Oct 20, 2008 at 03:30:44PM -0700, David T. Harris wrote:
> --- On Mon, 10/20/08, Chad Perrin <perrin@apotheon.com> wrote:
> > > As you know though, security v.s. usability/features
> > is a tradeoff.
> >
> > I disagree:
> >
> > http://blogs.techrepublic.com.com/security/?p=390
> >
> > >
> > > Proper development requires rigorous testing and code
> > auditing
> > > to prevent bugs and security holes.
> >
> > . . . which in no way trades away usability for any gained
> > security.
> >
> Please note I'm not a security expert, but this is the way things logically seem to me, at least.
>
> Usability - no, features - yes. Or at least it takes longer for features to get pushed to the stable release of a product. What I mean is that if you haven't rigorously tested something, it takes longer to make that product available in a secure environment (i.e. rigorous testing takes time, and the longer something takes the more consumers get restless as they wait for feature 'x'). Once it is available, yes you can have a secure system with secure features.
>
> Plus certain 'features' are a security hazard by some. For instance most web hosts provide ftp. This is a security risk because the ftp protocol allows for sending passwords as clear text. If you wanted to be security minded you wouldn't allow ftp access to your server.
>
FTP's *functionality* is what you're actually after -- right? You want
to be able to upload and download files using something akin to the FTP
protocol's interface. FTP is an unsecured implementation of the idea,
but it is not *in and of itself* a "feature". The exact same usability
can be had security via SFTP, which is provided as part of the OpenSSH
suite of tools.
> Why is ftp insecure - probably because it wasn't written with security in mind, like you mention in your article, Chad. However, the fact remains that it is insecure (for anything other than anonymous access) and yet used by many.
>
> Telnet is another example of this, though that at least seems to not be used anymore for remote sessions, but rather other uses (like port knocking) where logins aren't needed.
>
> One could counter-argue that one could just use sftp but the issue there is that sftp is not available by default on every major operating system like ftp is.
That's not the fault of "security vs. usability" or of "security vs.
features". Rather, it's the fault of short-sighted network
administrators and managers at shared hosting providers. Adding support
for SFTP would in no way restrict the feature set of the shared hosting
accounts -- and eliminating unencrypted FTP support once SFTP support is
in place wouldn't result in a "usability trade-off" either.
>
> In any *nix system it is not generally straightforward for a normal user to be able to install anything, especially using a normal installation program. Most binaries are prepackaged with system directories hardcoded in the binary itself. Hence you have to resort to installing via source if you're stuck on a system where you don't have admin rights.
>
> This is an example of security v.s. usability. You could add a sudo clause which gives them access to a program like apt-get but then they could install anything/everything and worse yet into system directories, not just their own home directory.
>
The fact that some Unix-like OSes don't provide helpful, "friendly" tools
to manage installation from source is not the fault of "security". The
fact that, when software management systems are provided that suit one's
needs, they often are not well suited to doing per-user installs, is also
not the fault of "security".
. . . also, it's worth noting that sudo is pretty darned configurable, so
that if you really wanted to you could bend it to the needs you imply
above.
> Yes, the installation program could have been written to account for users being able to install applications on something like a whitelist into a specific user directory, but that hasn't been done, and giving users acccess to the current install programs that install programs into system directories wouldn't be a secure solution.
>
The fact it hasn't been done is the problem -- not the fact that it would
be more secure. When you say that security and usability exist in sort
of a trade-off balance, you imply that *security itself* is the problem.
When you talk about the lack of tools to do things *right*, it's the lack
of tools -- and the tendency of developers to produce tools that do
things *wrong* -- that is revealed to be the real problem.
-- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] Power corrupts. The command line corrupts absolutely.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:26:36 EDT