6

I am running Apache Tomcat on a Windows 2003 Server and I have data stored in a mySQL database.

How can I prevent that a server admin can see any data?

6
  • 7
    Why would you want to? The server administrator is the one person with whom you can completely trust the entire server. If that person is abusing that trust, then inform their boss, and they'll be replaced faster than you can say "SQL". Or find another hosting company.
    – Ernie
    Jul 27, 2009 at 17:50
  • 1
    There is personal employee data like salaries. You don't want the server admin to know all salaries.
    – CL23
    Jul 27, 2009 at 18:00
  • 2
    The only way around that is for the admin to set up a server for you, let you change the passwords to whatever you like, and then never ask him to fix it.
    – Ernie
    Jul 27, 2009 at 18:39
  • 1
    @Ernie: Unless you're going to check all the binaries on the system against known-uncorrupted sources I'd argue that even that method has problems. Jul 27, 2009 at 18:44
  • @Evan: If you have that little trust in the admin that you can't even expect him not to peek at the salaries, I think that someone will find an excuse for him not to be working there in short order.
    – Ernie
    Jul 27, 2009 at 19:05

7 Answers 7

23

You can't, really.

The "Administrator" user on a Windows machine has complete control of that machine. That's "how it is".

Someone will probably suggest you encrypt the data in the database. Assuming that the keys for that encryption are located somewhere on that computer (since you'll wnat the application to have acess to them) the "Administrator" can just take that key and decrypt the data.

Someone else will suggest that you use some kind of file permissions. That won't work either-- the "Administrator" can just change them.

If you can't give your "Administrator" user a limited account with which they can accomplish all their day-to-day activities but otherwise is not an "Administrator", the only answer is "don't store that kind of data there". Any "answer" that involves the "Administrator" user retaining their "Administrator" rights won't give you any real protection.

An Edit for JimB's sake:

JimB left a few comments that I think deserve a longer response than I can give in a comment, so I'm dropping an edit on here.

I answered the poster's question w/ technical accuracy w/ respect to the privileges granted to the Windows "Administrators" group. The poster is certainly free to spend all the time he wants "tweaking" the default security permissions in the operating system to attempt to either (a) strip the "Administrators" group of the root-equivalent privileges (which, I would expect, Microsoft would tell you not to do) or (b) create a lesser-privileged group that could perform all the necessary day-to-day server administration functions but would not otherwise be an "Administrator".

Unless the poster's "server admin" needs are very basic, I would guess that the poster is going to end up getting into uncharted and undocumented territory.

Maybe the poster needs a "server admin" that can perform only very basic operations to the server computer and the "Administrator" password can be set to an arbitrarily complex string and stored in a locked safe. That's one possible strategy, if the poster's business requirements re: a "server admin" allow such a thing.

If the poster's requirements are more complex, I would expect that a LOT of ACLs (in the filesystem, registry, global object manager, and service control manager, at least) would need to be changed to accomodate giving a non-"Administrators" group member a close approximation of the abilities of an "Administrators" group member. The poster would also lose the utility of the well-known BUILTIN\Administrators SID, too.

I would be shocked if there aren't some assumptions running pretty deeply into the Windows NT OS about the out-of-the-box privileges assigned to members of the "Administrators" group. Attempting to take away privileges from the BUILTIN\Administrators group is, to my mind, asking for instability and problems with the OS.


I've not made any statements about "business policy" enforcing security. I don't know what JimB got out of my post or comments that gave him that idea. Business policy can't change the way that code works, and all my statements relate to how code works.

Auditing that a breach occurred doesn't mitigate that the breach occurred. You can know that someone breached confidentiality, but no auditing mechanism can tell you how many or few copies of the confidential bits were made after confidentiality was breached. It's boolean-- either confidentiality has been breached or it hasn't. Auditing can tell you that, and nothing more.

A business can attempt to "enforce security" in all the "business policy" that they would like, but unless that "business policy" is congruous with how the code, and reality, operates it's really pretty meaningless.

9
  • Hmm, that is frustrating to hear. Thanks for the answer!
    – CL23
    Jul 27, 2009 at 17:53
  • I used to think that too. Until I tried using a Windows machine as Administrator. There's lots that the operating system prevents you from doing, like killing processes that pretend to be system processes. It's one of the things that I like about using Unix - it never questions the root user.
    – Ernie
    Jul 27, 2009 at 17:57
  • 4
    @Ernie: It's really, really easy to get around just about every "protection" that Windows throws in front of you. The GUI "protects" you, but if you're using command-line tools or scripts you really can "do anything" as "Administrator". (Once you've used "Administrator"-level access to get a SYSTEM-level command prompt all bets are off. Wanna go delete the contents of the "Local Users and Groups" portion of the registry? Have at! It's wide open once you get to that point...) Jul 27, 2009 at 18:02
  • @evan - I'd agree that the default permissions are failrly open (although with auditing and alerting set up you'd still get caught) but you certainly can lock those permissions down. Administrator is just the default name of an account with a well known sid- nothing more.
    – Jim B
    Jul 27, 2009 at 18:13
  • 2
    @Jim: The "big deal" with the RID 500 "Administrator" or any account that has "SeTcbPrivilege" granted to it is the ability to subvert any operating system controls. Auditing is fine assuing that (a) you can winnow the amount of audit data gathered down to a manageable level, and (b) someone actually monitors the auditing data. In terms of breaches of confidentiality auditing that the breach occurred doesn't mitigate the breach. Any account with the "SeTcbPrivilege" granted can do anything it wants to the OS and there's nothing you can do to prevent it-- only to detect it after the fact. Jul 27, 2009 at 18:44
4

The above, but I'd add that an unethical administrator is worth nothing. If you don't trust your sysadmin not to peek (except as required to complete his duties), then you really need to find a replacement.

3
  • Well, this question question came up in a meeting today and noone knew an answer. I hope my company selects admins wisely.
    – CL23
    Jul 27, 2009 at 18:05
  • +1 for putting succintly what I was trying to say in comments. :)
    – Ernie
    Jul 27, 2009 at 18:42
  • 4
    Just want to add that it's possible that the person with a lack of trust is the problem rather than the Administrator.
    – Carl C
    Jul 27, 2009 at 18:58
2

In general, you can make it so Administrative accounts can not do things, but the Administrators can generally enable it so they can.

For instance, you can deny read access to a directory for the user Administrator, but the administrator could give themselves access again if they wanted.

So with this, I think you can (but not sure) , just deny read access to said databases by editing the MySQL privileges for the root user in the MySQL database. But this isn't real security. Or, you can not give the administrator any of the passwords of MySQL, but they can probably find a way to view the data if they have access to the server (or even reset the root password).

1

The points Evan brought up are one of the reasons sysadmins get such heavy background checks at my job. Everyone ultimately has to trust their data to us, and each has their own requirements for 'trust'. On some systems it is possible to lock out the sysadmin, but Windows is not such a system.

There are some things you can do at the application level to obfuscate your data from nosy sysadmins, such as using tables with encrypted data in them. That relies on having the encryption keys and the data in different sysadmin-domains though, otherwise there isn't much point. An example of this would be a Tomcat/PHP application running on a Linux server, and under the ageis of the Linux sysadmins, with the database in MS-SQL, under the ageis of the Microsoft sysadmins. Presuming the Linux/MS admins don't collude, the data is less likely to be snooped into.

1

You can deny the administrator access to anything you want. Administrator simply has, by default, rights over just about everything. What you can't remove (at least I've never done it- it might atually be possible but I wouldn't recommend it) is the abilty for the administrator to take ownership of the files in question and read them- however, that's auditable and irreversable- there's no grant ownership power.

administrator is a special account but it is not equivalent to root on a unix box. This is as common misconception.

You can also use the file classification infrastructure in a month or so when 2008 R2 comes out.

5
  • Thanks for your answer! Can't vote you guys up, because still <15 points...
    – CL23
    Jul 27, 2009 at 17:53
  • 1
    @JimB: The ability to "take ownership of the files in question" is SeTcbPrivilege, which I talk about in a response to a comment you left on my answer. Trying to take that away from the RID 500 Administator account is likely to cause major problems. At the very least, every version of Windows NT has allowed "Administrators" the SeTcbPrivilege, and I can't imagine that Microsoft would "support" a change to that setting. Jul 27, 2009 at 20:23
  • @evan- consolidating reponses up above
    – Jim B
    Jul 28, 2009 at 14:36
  • There is no grant ownership built in to the Explorer GUI, but administrators can set ownership to other accounts using tools like chown for Windows NT - wwwthep.physik.uni-mainz.de/~frink/chown/readme.html Oct 16, 2010 at 6:21
  • Chown requires that you have administrative access to the files specifically Backup, Restore and Take Ownership privileges (with AdjustTokenPrivileges()). These should be removed
    – Jim B
    Oct 21, 2010 at 17:39
0

Most mainstream operating systems (Linux, Windows, Mac OS X) cannot do this directly. There is always an account that may do everything on the system (Administrator, or root), and this account is necessary for many administrative tasks. No way around it, really.

To make this possible, you need something like a Multi-level secure OS, or one that supports Mandatory access controls. Something like SELinux, or Trusted Solaris, or Mandatory Integrity Control under Windows Vista.

Still, this is very complex to set up, and may cause compatibility problems with apps that were not written with the restrictions in mind. And ultimately someone will still have to have access to change security settings.

So while it is technically possible, you should carefully evaluate whether it is worth the extra complications and expenses.

3
  • Even in SELinux if you're root, you can do 'setenforce 0' and you're free again. In Trusted Solaris you don't have one root, you got four of them, with 'partial' powers of traditional root. Good idea, but it's kinda difficult to get anything done, if you need multiple people executing different commands.
    – Marcin
    Aug 6, 2009 at 11:49
  • @Marcin: You can disable 'setenforce 0' in SELinux if you want to (see e.g. crypt.gen.nz/selinux/faq.html#GA.8). But of course you can always reboot...
    – sleske
    Aug 6, 2009 at 16:28
  • @Marcin: "it's kinda difficult to get anything done[...]" Just my point :-).
    – sleske
    Aug 6, 2009 at 16:28
0

Access the payroll from designated workstations that the particular admin does not have any rights or physical access to.

Encrypt/Decrypt the data client side so when it arrives/leaves the server, it is always encrypted. It is only unencrypted at the client end and then only when the user provides the proper passphrase or keys.

Build a client program that encrypts the data before sending it off or copy the code from the OpenSource ClipperZ password management project. ClipperZ uses javascript to do this encryption in the browser. Needless to say, only use a very locked down selinux sandboxed webbrowser with a firefox profile specifically setup just for payroll. Not email. Nothing else.

You may even consider still having the server encrypt it to mitigate some forms of client side rootkits - especially a man-in-the-browser.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .