Re: Installation and setup of secure applications

[Erik van Konijnenburg <ekonijn () xs4all nl>]

On Tue, Jan 20, 2004 at 05:22:35PM -0200, Andreas Saurwein wrote:
> And, focusing on Windows NT (2000, XP, 2003), security is not an easy task. 
> How many programmers can you name who know what is an ACL, ACE, or process 
> token? How many of these few know how to atually use it in their applications?
> ...
> > Should applications be designed and implemented such that they make extensive
> > use of their host OS security features?  Note that I'm not saying that they
> > should _rely_ on it, but should the developers make more use of the
> > capabilities available to them (sometimes at the cost of easy portability) as
> > one of many layers of defense?  If so, how much is {enough|too much}?
>
> Yes they should be designed to make extensive use of the OS and its 
> features. The few that do it already are successful applications.
> There is just the big danger to "rely" on the security of the OS without 
> knowing it and thus unknowingly adding securityholes to the application.

There's a risk of unclear responsibilities here: the use of impersonation.

In a simple model, there are three players: user, application and system.
Think of applications as daemons, with multiple daemons running on a system,
users connecting to multiple applications and perhaps storing files
somewhere on the system as well.

The responsibilities:
- User's must choose between trusting the application with their
  application data or foregoing the use of it,
- applications are responsible for not allowing users to access
  each others application data,
- and the system is responsible for providing authentication and
  not letting applications access each others data.  As a consequence
  the system is responsible for not allowing applications to compromise
  the integrity of the system itself.

Perhaps applications also have some limited trust for each other:
an inventory application may trust the web store not to forward an
order until the credit card has been accepted.  In a similar vein,
a system may choose to trust the authentication done by another system.

The objective here is damage containment: if the mail service has been
compromised, as a user I want the system to guarantee that my time
sheets have not been affected.

The canonical implementation is straightforward: have daemons run
under different accounts, let users authenticate with eg Kerberos
and protect the underlying storage of the daemons from everybody
except the application administrator using file system permissions.

Now add impersonation: a nifty feature in the operating system that
allows the application to use the credentials of the user to do stuff
on behalf of the user.  In for example IIS this is actually used:
the user logs in to the web server, the web server takes on the
credentials of the user, fetches the page from the file system,
and if that works the user is authorised to access the web page.
The effect is that the webmaster can administer web access permissions
right from the file system explorer.  Nice.

Consider what this does to damage containment.  In the first place
this makes it necessary to give the application some capabilities
that come close to complete ownership of the system.  Second, since
the application can operate under the credentials of the user,
any file accessible to the user is now potentially affected.
Finally, the simple division of responsibilities is gone, and it
becomes much harder to think about what properties each party
must protect and what can be safely left to the lower layers.

Thus, I believe impersonation is a tempting but evil concept that
should be avoided in applications.  Perhaps we can generalise to
say that applications should only be allowed to use host OS security
features in self defence, in a minimalist manner.  That would mean:

- using file system permissions to protect application data from
  third parties is OK.
- using file system permissions to protect the program from the daemon
  running the program is OK.  If the program is to be modified,
  I'd rather it's done by an administator than by some worm.
- using OS provided authentication is OK.  It's a good first step
  towards single sign on, in particular if your OS supports pluggable
  authentication modules.
- using impersonation, well ...
- using OS provided user groups to manage permission is somewhere
  on the border line.  You could make a case that this is really
  using the OS as a directory for the administration of user rights,
  and that opens the perspective of streamlining that administration
  more than is possible than in an approach where every application
  has its private user management interface.
  On the other hand, in for example a web store or forum,
  the population of application users will hardly overlap with
  the system users.  Using the system provided directory is a
  good precaution against unwanted market uptake here ...

Rereading, the above sounds way too much like a lesson expounding
eternal thruths, but frankly I'm none too sure about whether this is
a workable model.  Anybody got some good counter examples?

Regards,
Erik