--- Joshua Brindle <[EMAIL PROTECTED]> wrote: > Casey Schaufler wrote: > > --- Joshua Brindle <[EMAIL PROTECTED]> wrote: > > <snip>
<snip> > > 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? Named pipes require read access to open, even for O_WRONLY, like all other file system objects. > Sockets (datagram and stream) have similar backchannels related to > blocking state and buffer size. INET domain UDP provides neither blocking nor buffering feedback that I'm aware of. That's why I'm using it. What am I missing? > <more snip> > > > 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. Right. And I think you've hit the difference between SELinux and Smack. SELinux accomodates the notion that this application can talk to that application whereas Smack holds strictly to whether this process can talk to that process. SELinux can specify a finer granularity through the policy definition, but also assumes that the application's behavior is proper within the bounds of the policy. Smack does not take the intent of the program into account. > >> 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... Sigh. Another tool to learn. > > >> 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. HeeHee. I'll keep you posted. 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
