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.
-
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
