Casey Schaufler wrote:
--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
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.
UDP is a datagram protocol that does not provide feedback regarding
delivery. Each communication step uses UDP and no other means to send
information in one direction.
What backchannel are you concerned with?
read below.
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).
The whole point of a guardbox is to look at the data being
transmitted. Breaking the system to object class, or any other
granularity, is not going to change the content inspection
process. And the whole point of a guardbox is to selectively
downgrade data based on the makeup of that data.
So I guess I'm just confused.
Yes, and in the "old days" it was fine to essentially trust the entire
mechanism that looked at the data but more recently _some of us_ have
decided that we don't really want to completely trust that mechanism so
we break it into a bunch of small pieces and use MAC to ensure the
unidirectionality (a so called 'assured pipeline').
So with SIPC we can have 5 filters and 2 endpoint processes that each
have a very high forward throughput and a very low bandwidth backchannel
and one has to compromise all of them to get information through that
wasn't suppose to get through (and still they have a very low bandwidth
channel they have to use).
With smack this isn't the case, if every process gets compromised they
can just make connections to each other that utilize other IPC
mechanisms that have higher throughput backchannels. One example is to
use pipes, quoted from the paper I referred to earlier in this thread:
""The write system call provides another back channel
for non-blocking FIFOs. The write system call is
implemented in such a way that it writes as many
bytes as possible and returns the number of bytes
successfully written. Using this knowledge, it would
be possible for B to manipulate the size of the buffer
by only reading a certain amount of data, thereby
causing a value to be transmitted back to A via the
write call. This channel could transfer large amounts
of data even with SELinux enforcing unidirectionality
on the data pipeline.""
Since smack doesn't provide object class granularity it can't (at least
as of yet) protect against this kind of attack.
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.
Cool. When will we see the Smack port?
There is no SELinux specific code in it, anyone can use it anywhere (but
it is only useful where there is MAC to enforce its model)
One part of the model, however, is to have a helper app that creates the
message queues. This was implemented so that A couldn't create arbitrary
amounts of queues and use the blocking backchannel to increase the
backchannel bandwidth. Since smack doesn't implement that level of
permission granularity you'd have problems implementing the necessary
controls.
-
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
