Directory encryption

[Daniel Fourie]

I would like to know if it is possible to setup encryption for a directory where files are stored. Meaning I would like this directory be protected by a key or password.

Any help will be thankfull

[Bill Hassell]

There is nothing in standard HP-UX that can do this. The problem is that there are MANY different ways to access a directory and every command and library that deals with files would have to be changed. And of course, scripted solutions (and cron jobs) would have big problems running without user intervention.

The problem you describe is easily solved by changing the permissions to 700 for the directory and make it owned by the user that has the right to look at it. All other users will see: dir_name unreadable. If you need more than one user to look at the directory, use ACL's (man acl).

[Daniel Fourie]

That sounds great, but how do I block root from accessing this directory.

[Rainer von Bongartz]

That's exactly the problem......

Regards
Rainer

[Steven E. Protter]

This matter is handled on HP-UX boxes by systems administrators that take the time to plan out group and user permissions, set umasks and if necessary use JFS ACL's

SEP

[Massimo Bianchi]

root can do anything... but no-one, except administrators, should have a root account.

Massimo

[Tim D Fulford]

Some people/companies think a 3rd party (usually security) should have root password & only allow sys-admins to use it upon request!!

e.g. No one uses root

Tim

[Jason Deckard]

Encrypting the directory entry itself would be difficult and, I believe, ineffective.

Using open() to access the directory entry will return an error (EISDIR). If you had a way to read the directory information into memory, encrypt it, and write it back to disk, the OS would probably complain (or worse). Even if you could encrypt the directory entry AND it didn't cause problems with the OS, you are merely encrypting the directory entry itself and not the files within the directory (it may be difficult for someone to access the files in that directory, but the files would still be in plain text).

Perhaps it would be better to create a utility that encrypted every file in the directory, while leaving the directory entry itself alone. Is that the answer you were looking for or am I taking the question a bit too literally?

[Steven Sim Kok Leong]

Hi,

To add on, one pretty effective way of hiding directories from view and be only accessible with a proper login is via a chroot cage.

A chroot cage creates a virtual root where the user has access to but no other directories beyond that. One classic example is anonymous FTP. It is a chroot cage with a virtual / directory. Any anonymous user will not have access to your actual real / and beyond. Only legitimate users with proper userids and passwords can access your real / directories and subdirectories, given the right permissions of course.

Note that using rsh (restricted shell) does not prevent users from accessing the real /.

Hope this helps. Regards.

Steven Sim Kok Leong

[Steven Sim Kok Leong]

Hi,

You can block root access by making use of tools such as Platinum AutoSecure or equivalent tools. They allow you to limit what root can do.

Only a different security administrator that manages the AutoSecure configuration can assign privileges to root but the security administrator himself cannot create a superuser account for himself.

Here's more details on AutoSecure from a pretty old article. I last heard it has been bought over by Computer Associates but I can't remember the exact new name. I believe it is part of CA eTrust Suite.

http://www.industrywriter.com/Platinum_samples/Autosecure%20article.htm

An extract on the relevant:

Limiting the power of root ??? A well known feature of UNIX is its use of Root ??? or Superuser ??? authority to provide an administrator with access to sensitive system files and resources. Unfortunately, and all too often, users who have no business performing system administrative tasks are able to indirectly establish root authority and gain access to restricted files. AutoSecure copes with this vulnerability by totally encapsulating Root, instead of simply trying to hide it or work around it. The result is that a user or object with Root authority is required to pass the same authorization checking as a regular user and cannot gain superuser access to system resources unless AutoSecure authorizes it. And regular users cannot change their login ids in order to assume the id of someone with Root user authorization.

Hope this helps. Regards.

Steven Sim Kok Leong