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
