Casey Schaufler wrote:
--- Joshua Brindle <[EMAIL PROTECTED]> wrote:
<snip>
The guardbox I proposed has no backchannel. The origin daemon
can write to the guard, but not read, and the guard can neither
write to nor read from the origin. Similarly the guard can write
to the publisher, and the publisher cannot read either origin or
guard data, nor write anything back.
All IPC (aside from perhaps sysv shm) have overt backchannels, that is
what the document I pointed you to is about. An example of a backchannel
is an IPC that only allows a certain amount of data (up to the buffer
size) to be passed on and returns that size. Using this process B can
manipulate the size of its buffer to send messages back to process A
(even though A can only "write" and B can only "read").
I have considered a distinct backchannel path that uses it's own
daemon to which the guard can write and that can write to the origin
daemon. That code is simple enough, and has the same sort of issues
that the guard does regarding compromise.
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).
Right, with I scheme I've outlined the only way to get bad information
to the origin is for the publisher to put it where the origin can read
it.
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.
Ah. And those IPC mechanisms would be ...
One example is to use pipes,
Since unprivileged programs (the origin, guard, and publication
daemons in smackguard run without privilege) can't change their
Smack labels establishing a pipe between processes with different
labels is not possible without privilege.
That may be the case with unnamed pipes but what about named ones?
Sockets (datagram and stream) have similar backchannels related to
blocking state and buffer size.
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.""
It looks to me like SELinux has the weakness, allowing this
IPC to be used in this way whereas Smack does not by prohibiting
the scenario in the first place.
Well, its policy driven so those of us actually concerned with it don't
allow it. Functionally speaking alot of apps all over the system have to
talk to each other in various ways, we like to be specific about how
they can talk to each other, thus the object class granularity.
Since smack doesn't provide object class granularity it can't (at least
as of yet) protect against this kind of attack.
How does object class granularity protect against this kind of attack?
If you're suggesting that you use it to prevent the application from
using pipes, I have a coarser grained solution, which is to not let
the application use any mechanism that allows the prohibited
communication, and that would include pipes.
Pipes are a really poor example because of the way that they
are created and shared only by processes related by fork(). Smack
has no trouble with pipes because the endpoints will always
have the same Smack value in the absence of privilege.
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)
Also cool. Can you point me at the current version, and I'll see
about putting together a Smack based package.
Yes, http://oss.tresys.com/projects/sipc/ is the webpage, it looks like
we only have an svn repo of it up right now, not packaged sources, that
shouldn't be a problem though. Note there may be some API changes coming
soon...
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.
That sounds like a challenge to me. Good fun.
Great, I'd love to see if the system we designed is actually generally
applicable.
-
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
