Message-ID: <Pine.LNX.4.58.0410011502020.8830@guildenstern.oneview.local>
Date: Fri, 1 Oct 2004 16:16:54 -0500 (EST)
From: "Jason T. Miller" <jasomill@...oneview.com>
To: "Greg A. Woods" <woods@...nix.com>
Cc: bugtraq@...urityFocus.com
Subject: Re: cdrecord local root exploit


On Fri, 1 Oct 2004, Greg A. Woods wrote:

> However with the limitations of file and process ACL technology present
> in most unix-like systems following this principle gets a lot more
> difficult if, for example, you want to have a second limited group of
> users be able to write to a configuration file for the program, but not
> make it possible for the program itself to write to any of its
> configuration files (e.g. if it were to suffer a buffer overflow and
> give its privileges to an attacker).  As far as I've ever been able to
> figure out it's almost impossible to do this on unix-like systems if you
> also need to protect the content of the configuration file from prying
> eyes (i.e. not be "other"-readable).

You can do this with the help of sudo -- create a user (not group) to
administer the file and a group which the program user is a member of. Set
the file 0640, owned by admin-user:program-group, then let the users who
need to administer the file run as admin-user (who is otherwise
unpriviliged) using sudo. Unlike user owners, group owners have no control
over permissions. Obviously, program-group shouldn't have write access to
the config file's directory (else it could simply unlink and re-create the
config file).

Unless you limit sudo to allow execution of a _very_ restricted editor,
the admin users could create files as admin-user, subverting quotas, but
this seems minor, especially as you could severely restrict admin-user's
quota. If you have some form of object-access auditing on your system,
edits to the config file would look like they were being done by
admin-user and not the real user, but sudo has pretty good logging
facilities itself.

This solution also gets around another nasty UNIX security limitation --
in FreeBSD at least, group memberships are stored in a
statically-allocated array whose default size is 16 entries. This limit
can be increased by changing header files and rebuilding the OS (no help
for binary-only systems), but this hurts performance, requires lots of
stuff to be rebuilt, and supposedly can lead to other problems.

Under FreeBSD, you could also let the admin users run as root in a jail,
and make the config file owned (and only writeable) by root, but this is
overkill unless want to use jails anyway. You could also combine the
techniques (let users use sudo, but only in a jail, etc.).

> Such complexity though is an enemy of security.

Very true. From what I can see, configuration complexity is the primary
reason why the (technically) superior privilege model in Windows winds up
being less secure in practice than the simpler UNIX model. Not only does
such complexity make it easier to foul up (and more difficult to test), it
encourages the practice of running services and applications in
unnecessarily privileged contexts (e.g., as a machine or domain
Administrator or LocalSystem) -- often developers and admins are lazy,
more often they are overworked and have more (visibly) pressing things to
worry about than figuring out exactly what priviliges their applications
actually require.

Microsoft or a third-party might do well to provide automated tools to
ease this process (if such tools don't already exist), say, a harness
which audits object access and privilege use and produces code to
automatically generate "least-privileged" users and sets file permissions
appropriately, which could be incorporated into the program's installer
(perhaps it could also integrate with the Windows Security Configuration
Manager). There are some technical details to be worked out, most notably:
all code paths would have to be exercised (no way to automate this); SACLs
would have to be added to every object in the system (shouldn't be a big
deal on a development system, as long as they're subsequently removed);
many programs in fact request more access than then use (the tool could
point this out, but this would add complexity as the Windows auditing
system can't detect it, you'd have to trap API calls or something), but it
would be a useful tool to have. I've spent many hours doing this manually
with the Event Log and negative (failure) ACEs in the SACL, and it's not
much fun.

 -jtm

Powered by blists - more mailing lists