secure software philosophy (was Re: 2.4.x/Slackware Init script vulnerability)

[Derek Martin <ddm () pizzashack org>]

Keith, thanks for your comments.  I found them quite informative and
helpful in understanding this issue.  I think that everyone on this
list would agree that system security is an important topic, and one
that will continue to increase in importance as more and more systems
are connected to the Internet, and more aspects of our daily lives are
carried out on the Internet.  I would like to share some thoughts and
opinions on your response as they pertain to modutils, and to software
development in general, which I hope you and the community will find
useful or thought-provoking, even if you don't agree with everything I
say here.

On Wed, Jul 18, 2001 at 09:59:43AM +1000, Keith Owens wrote:

> > I would think that modutils should set the creation mode to 0644 when
> > creating these files.  I would also think that as a security measure,
> > modutils should verify that these files (or at least modules.dep) are
> > not world-writable (and probably also not group writable) BEFORE
> > loading modules as a result of listed dependencies...
>
> When programs should force security settings and when they should trust
> the umask is a policy question.

I agree with this statement; but I think it warrants further
consideration.  I'm a system administrator, and by the nature of my
job I have a different philosophy about how things should be
configured than software/OS developers typically do.  The sysadmin
generally leans toward security, and the developer leans toward ease
of use (openness).  Neither philosophy is wrong, they're just
different; and each should be used when it is appropriate.  For the
most part, most of these two groups knows how to configure their
system for what they want, or at least is technical enough to go about
figuring out how... 

But there also is a growing third group of people emerging as Linux
users: the average Joe.  There are many reasons why people are moving
to Linux today, not the least of which is Microsoft's renowned buggy
and/or insecure code, and the fact that Linux advocates keep saying
that Linux is more reliable and more secure than Windows (which I
agree with based on my own experience).  Whether or not that's
actually true or provable, that's what people are saying, and it's
bringing the non-technical computer user into the Linux forefront.

These people have no idea what information assurance/network security
is, never mind how to configure their systems for it.  These people
have no idea what they're getting themselves into when they install a
Linux system (using the average distribution's standard installs) and
connecting it up to the Internet.  Odds are these days that they'll be
hacked within a week, and probably less.  Because of the potential
seriousness of the consequences of having your systems and data
compromised, and because of the negative impact going through this
experience can have on users new to Linux (or experienced ones for
that matter), I think that for the good of the entire Linux community,
the development community ought to make security a priority.

In other words, yes, developers will want to do things that would put
most other Linux users at risk; HOWEVER, while I think it should be
possible for them to do those things, I also think it should be HARDER
to configure your system to be less secure than it should be to have
it configured reletively securely for every day use.  (I'm
deliberately trying to avoid absolutes because, as we all know, in
practice there is no such thing as a completely secure machine -- at
least not one that's usable by anyone -- and improving security
negatively impacts convenience and usability.  A balance must be
struck somehow.  I'll dance around that a little more below.)

That is to say, you should have to make a deliberate effort to reduce
the security of your machine, if you need to do so for development or
whatever other reason...  Or said another way, if a particular
software package (or the kernel itself) can be used in a way which is
known to open up your system to root compromises, that should NOT be
the default: the program which is capable of this should not assume
anything about the environment it runs in (like umask) if incorrect
assumtions result in a root compromise or other unauthorized elevated
priviledge.  I might go so far as to say it should assume the
worst-case scenario (e.g. for this case, that the umask will always be
000), in order to prevent .

> Users on development systems deliberately create modules.dep as 666
> and allow modules to be owned as other than root so modutils allows
> this.  In this case I decided that the policy setting should come
> from the user via umask, instead of being forced by the programs.

At least on my "broken" Red Hat 6.2 system, you can still do this if
modutils creates the files 0644.  Except you must do it explicitly.
If you chmod the files to 0666, they will retain those permissions
(assuming the given distribution doesn't go out of it's way to remove
the modules.* files) after subsequent reboots.  But the burden to make
the system less secure, and the responsibility for the consequences,
has been placed on the user/administrator, where I think it belongs.

> If root's umask is 000 then lots of programs are insecure, should
> all of those programs be changed to ignore umask?

First, you're not ignoring umask.  You're simply defining a minimum
set of permissions that the file(s) should have by default.  I think
this is reasonable to do.  Maybe you can make it a compile-time
option...  In any case, you could set root's umask to 077, and the
files would then be created 0600 (ignoring whether or not this would
break things)...  As to whether or not you want your processes to use
pre-defined minimum permissions, my answer would be a qualified "YES!"
The qualification is that it should only be done in cases where a) it
will not make the software unusable, and b) not doing it can easily
result in an elevation of priviledges of a regular user, where the
only mitigating factor is the environment of a given process, about
which I think you must not make assumptions.

This particular case is a good example of what I mean: a root
compromise is possible if the distribution maintainer(s) or the system
administrators forget/overlook/fail to see the need to set the umask
"properly" to avoid the problem.  An operating system is complex; with
all the software that comes with your average Linux distribution --
written by a wide variety of individuals with (usually) no particular
holistic design philosophy, such as a proprietary OS (ostensibly) has
-- I should think that putting together such a beast is even more
complex than designing a proprietary OS would be. It should be
expected that the people who build distributions WILL overlook these
little details, as it happens all the time, as this case illustrates.
If you, as the software developer -- the guy (or gal) who knows the
code better than anyone else -- can prevent this from happening,
without actually preventing those who NEED to open up the system from
being able to do so, then I think it's in your best interest and the
interest of the community as a whole that you do so.  Some might even
argue you have a duty to do so.  Exactly that is argued about
Microsoft all the time, often by the Linux development community
itself.

I'm disinclined to say you have that duty.  I think that Linux
developers largely write software to suit their needs, and have no
responsibility to anyone to do anything they don't want to.  You are
giving your work away for free, after all... 

On the other hand, I do think that all of us who develop software
which we intend for others to use, especially in networked
environments and especially on the Internet, do have some
responsibility to make every effort to ensure that our software does
not cause the systems and data of its user to become compromised,
unavailable, or damaged.  I sincerely hope that everyone writing
software will take that responsibility seriously; as our society
becomes more dependent upon the Internet and network-connected
technologies, it also becomes more vulnerable to careless and insecure
coding practices, and we all play a part in that.

Thanks.


-- 
---------------------------------------------------
Derek Martin          |   Unix/Linux geek
ddm () pizzashack org    |   GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu

Attachment: _bin
Description: