Casey Schaufler wrote:
--- 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.
Both of which can also be done outside the application layer ;)
I'm still pretty sure that, while you might not be providing really high
throughput backchannels you aren't doing an incredible job of minimizing
them either. There are plenty backchannels in most Linux IPC and since
you don't provide object class granularity you are letting the
applications choose which ones they want (which would be the ones with
the biggest backchannels if they were trying to downgrade information).
I'll grant that just about every solution created doesn't really take
this into account but the SIPC effort was to make a library that could
be used by applications and a set of policies that made a very minimal
backchannel, high forward throughput and still have decent reliability.
We are, in fact, using SIPC on some solutions in development and it
seems pretty promising.
-
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
