This is all done in userspace and does not require an SELinux enabled kernel. This is a seperate orthognal system.
On Fri, Apr 19, 2013 at 7:04 AM, Kotikela, Srujan <[email protected] > wrote: > Hi Stephen, > > Thanks for the reply. So in future, when middleware MACs get merged in > seandroid, will every IPC event be routed to seandroid via LSM in the > Kernel? > > Thanks and regards, > Srujan D. Kotikela > > ________________________________________ > From: Stephen Smalley [[email protected]] > Sent: Thursday, April 18, 2013 2:17 PM > To: Kotikela, Srujan > Cc: [email protected] > Subject: Re: Middleware IPC in seandroid > > On 04/18/2013 03:02 PM, Kotikela, Srujan wrote: > > Hi, > > > > I am reading the paper on Seandroid, I have a question regarding IPC in > the android framework/middleware level. Does all these calls get trapped > into LSM and reviewed by seandroid? If not, does seandroid have a > user/middleware level component validating the middleware-level IPC? > > > > In other words, I am asking if all kinds of IPC will trap into the > kernel/LSM and reviewed by seandroid at kernel level? > > Ultimately the IPC occurs via the kernel binder driver, and at that > level there is a basic mediation of the aspects visible to the kernel, > e.g. can the sender perform IPC to the receiver, can the sender transfer > binder references or open files to the receiver, what process can > operate as the context manager, etc. > > However, the kernel does not attempt to interpret the data payload of > the IPC, and thus enforcement of higher level semantics is left to the > middleware MAC mechanism(s). There are experimental branches for > "intent MAC" and "content provider MAC", and work in progress to bring > them into a consistent approach. > > > > > > -- > This message was distributed to subscribers of the seandroid-list mailing > list. > If you no longer wish to subscribe, send mail to [email protected] > the words "unsubscribe seandroid-list" without quotes as the message. > -- Respectfully, William C Roberts
