--- Joshua Brindle <[EMAIL PROTECTED]> wrote: > Casey Schaufler wrote: > > --- 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) > > > > > > I may be confused but it seems like you are encoding part of the policy > into the application behavior rather than relying completely on smack to > implement the policy and prevent unintended information flow.
The checks that the deamons do on the incoming packets are not necessary to the policy enforcement. Checking the remote port and the delivery label are simple actions, so if you know what the value should be, why not have a peek? I'm sure that there are people who would insist on the data being encrypted and every packet checksummed. 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
