Another ACL question

[Michael Moroney]

Is it possible to set ACLs on a directory in such a way that an unprivileged process can create files in the directory, but cannot do a listing of files in the directory? I tried the obvious, granting Write+Execute protection for the UIC, but it seems you need Read+Write privilege to create a file in the directory.

Is it possible to set ACLs on a directory in such a way that an unprivileged process can create files in the directory, but once having done so, can no longer actually access those files? Setting a DEFAULT_PROTECTION ACL entry with S:RW,O,G,W protection sort of works, in that the file is created with that protection and the owner cannot access it, but the file is created as owned by the creator who can issue a $ SET PROTECTION on the file.

[John Gillings]

Michael,

I'm not sure if you can allow creation but deny listing the directory. For captive users you may be able to do something clever with a dynamic resource identifier. Enable it when they need to create files, and disable at other times. Use ACE order to explicitly allow or explicitly disallow access.

>Is it possible to set ACLs on a directory
>in such a way that an unprivileged process
>can create files in the directory, but
>once having done so, can no longer
>actually access those files?

Yes. It's done using a "project directory" owned by a resource identifier. The files end up being owned by the identifier, not the user that created them. There's a weird entity called the "creator ACE" which you can set to deny access.

Work through the example in the Guide to OpenVMS System Security. Get it working first, and then adjust to your needs. Look for "Project Account" in the index (I used to be able to say it was section 5.3.5.3, but now they've removed section numbers, I have trouble finding anything in the GOVSS :-(

[Ian Miller.]

See
http://h71000.www7.hp.com/doc/732FINAL/aa-q2hlg-te/00/00/78-con.html#resource-id-setup

and follow the references

[Hoff]

I don't know the sensitivity of the file data here, or whether the file contents or even the filename are considered particularly sensitive. Differences here can send a design in very different directions.

In general, this looks similar to a common and typical scholastic project submission sequence -- homework assignments, class projects, et al -- and the topic was commonly discussed back when OpenVMS was more widely used in schools and colleges.

Resource identifiers and subsystem identifiers are the usual approach, whether directly or through a small image that controls the submission.

OpenVMS in the guise of its SEVMS variant had an explicit sequence for upgrading information security sensitivity settings, but I digress.

DECnet or IP task-to-task -- built in DCL or otherwise -- can also be used, where the client tosses the filename at the server, and the server (operating privileged) copies in the file under an application-appropriate name and related processing.

Depending on the particular application, I'd probably also look to using a web server and uploading files that way, too.

The filename collisions and such were a common second-level error in the school tools, too, when a half-dozen folks all named their submission file HOMEWORK.TXT or such and an errant tool dutifully clobbered the previous version.

Directory protections are also a somewhat soft protection. The file itself (also) needs to be protected against access, or a brute-force attack is feasible.

I'd be surprised if there were not some similar tools still around -- the (old) Freeware package Cerberus comes to mind here, as does the execsymb package. Most cases of this problem have been solved before, after all.

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

>that an unprivileged process can create
>files in the directory, but once having
>done so, can no longer actually access
>those files?

Another (simpler?) way of looking at this operation... use MAIL:

$ MAIL file TRAPDOOR

If you run DELIVER, or a periodic script at the other end, you can automate extracting the files. This will allow you to make the target directory completely invisible to the senders, and resolve issues like filename clashes as raised by Hoff.

[Michael Moroney]

I should mention that this is (now) academic. About 4 years ago, UCX/TCPIP came with an open "anonymous" FTP account by default, and it was popular at the time for the "hackorz" of the net to put their cracked/stolen "warez" software on random systems on the internet, presumably passing pointers among themselves using a different channel. They quickly filled up the system disk of a hobbyist system. I wanted to see what they were up to but not "help" them, so I wanted to set up the anonymous FTP account to allow them to place files there but once having done so, they had no access to any of them. It seemed that no matter what ACLs I put on the anonymous FTP directory, VMS somehow always granted an additional ACL to created files allowing the creator access, defeating my plan. I finally thought better about all of this and simply disabled anonymous FTP.

Fast forward to a few weeks ago when someone asked me about something similar and I related my story how VMS tried to defeat my efforts. I didn't try having identifiers owning files.

For my original exercise, the files were created using FTP and better solutions like email or web access didn't apply.

[Michael Moroney]

See previous reply.