--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
> ... On the guard > implementation I'd like to note that assured pipelines are pretty hard > to get right. Without object class and create granularity (at the very > least) you might find it very difficult to control backflow. Consider > that 1) many IPC mechanisms in Linux have pretty big back channels, like > process B being able to pull X number of bits off a unix stream socket > and A being able to discover how much he pulled off. Also note > bitmap-style attacks where A can create lots of blocking IPC's and B can > go through and unblock the ones that he wants to be an 'on' bit. > > We have a paper on this you should read, > http://selinux-symposium.org/2007/papers/11-SecureIPC.pdf > > The solution in SELinux was to allow only a small, trusted helper app to > create the message queue (only 1) to avoid the bitmap attack so the only > overt back channel left is a very low bandwidth 'pop per time period' > style attack. We've gone through alot of effort to figure out how to > minimize the back channels in assured pipelines and still offer some > reasonable functionality, you'd probably benefit from the work we've > done on this topic. Since you've done your research on the topic I felt that it would only be fair if I did mine before responding. I took a simplistic approach to the problem and chose INET domain UDP datagrams as my mechanism for IPC and hacked together a suite of programs that implement a guardbox. The implementation is crude at best, and the "guard" lets anything through, but all the components are present. The suite consists of 5 programs: origin-sgp: a deamon that passes files from the origin directory to the guard deamon. guard-sgp: this deamon is passed files and decides if they should be passed along. Those that should are passed to the public deamon public-sgp: receives data from the guard and places it gently into the public repository. launch-sgp: fires up the three deamons above. ui-sgp: the user interface program, it sends publication requests to the origin deamon. These access rules are used: Origin Public rx - A process at the original label can read the Public repository. Handy for checking to see that the transfer was successful. Not required for the guardbox to work. Origin Guard w - The origin deamon can write to the guard deamon. Guard Public w - The guard deamon can write to the publicator. Each of the deamons checks that incoming packets: - come from the socket specified in the configuration file - come at the label specified in the configuration file - are part of a properly ordered set that makes a complete file. (well, the data's there, my hack doesn't check it very well) A user logged in with a Smack label of Origin runs "ui-sgp foo". ui-sgp "foo" -> origin-sgp origin-sgp verifies it's OK to open foo, and does so. origin-sgp file header -> guard-sgp origin-sgp data -> guard-sgp origin-sgp file trailer -> guard-sgp guard "processes" the file data, discarding what it dislikes. guard-sgp file header -> public-sgp guard-sgp data -> public-sgp guard-sgp file trailer -> public-sgp public-sgp gathers the file together, creates the public foo. The user does "ls public" and verifies the transfer. I'm happy to share the suite with anyone who'd like to see it on the condition that it's understood that it's intended to demonstrate how it's all done rather than to be used for real. I tried to isolate the Smack specifics into a single file in the hope that if someone wants to get it running under another security scheme they could do so. I expect that with some tweeking in that bit of code and some policy work it will work under SELinux. Casey Schaufler [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
