seinfo tag label

seinfo tag label

[Leonard Miyata]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

I've been tasked with working on the Middleware Flask implementation for the SE Android Project. After spending some time trying to figure out the existing Android Permission enforcement, as well as the current state of the SE Linux/Android implementation, I am starting to develop some concerns on the usefulness of the Middleware implementation of the seinfo tag information.

The seinfo tag is defined in 'class ApplicationInfo'. The 'class ActivityManagerService' maintains multiple Hash Sets of the current running applications (one indexed by packagename/uid, another indexed by pid) of 'class ProcessRecord', which contains a 'ApplicationInfo info' field that would contain the seinfo Tag information...

However, the comment in 'class ProcessRecord' for the 'ApplicationInfo info' field is "all about the first app in the process" which would seem to imply that you can have other apps, (possibly installed with different Security Properties) associated with the Process, and could be a potential loophole for Middleware Flask enforcement.

It could very well be that calling down to the SE Linux Kernel and extracting the Security Context associated with the pid may provide better 'trust' for a security 'tag', but I have yet to figure out the relationship between the 'Flask' labels returned by the SE Linux Security Context, and the X.509 Certs, (and associated digital signatures) used to verify the 'trust' levels of installed packages.

Any comments on this and Middleware Flask implementation in general?


Leonard Miyata

[-- Attachment #2: Type: text/html, Size: 3628 bytes --]

Re: seinfo tag label

[Stephen Smalley]

On Fri, 2012-08-03 at 18:36 -0500, Leonard Miyata wrote:
> I’ve been tasked with working on the Middleware Flask implementation
> for the SE Android Project. After spending some time trying to figure
> out the existing Android Permission enforcement, as well as the
> current state of the SE Linux/Android implementation, I am starting to
> develop some concerns on the usefulness of the Middleware
> implementation of the seinfo tag information.
> 
>  
> 
> The seinfo tag is defined in ‘class ApplicationInfo’. The ‘class
> ActivityManagerService’ maintains multiple Hash Sets of the current
> running applications (one indexed by packagename/uid, another indexed
> by pid) of ‘class ProcessRecord’, which contains a ‘ApplicationInfo
> info’ field that would contain the seinfo Tag information…
> 
>  
> 
> However, the comment in ‘class ProcessRecord’ for the ‘ApplicationInfo
> info’ field is “all about the first app in the process” which would
> seem to imply that you can have other apps, (possibly installed with
> different Security Properties) associated with the Process, and could
> be a potential loophole for Middleware Flask enforcement.

A given process will only run app components of a given UID (naturally,
as the process can only have one UID), and thus sharing within a process
can only occur within a UID.  As a UID can only be shared by apps signed
with the same certificate, you should never have a situation where a
different seinfo value (and thus a different SELinux security context)
would be assigned to an app running in the same process.

> It could very well be that calling down to the SE Linux Kernel and
> extracting the Security Context associated with the pid may provide
> better ‘trust’ for a security ‘tag’, but I have yet to figure out the
> relationship between the ‘Flask’ labels returned by the SE Linux
> Security Context, and the X.509 Certs, (and associated digital
> signatures) used to verify the ‘trust’ levels of installed packages.

The seinfo tag for the package is used to select the security context
for the process based on seapp_contexts.

The middleware Flask implementation would maintain its own notion of
security context for each app UID, which will not be the same as the
SELinux security context at the kernel layer.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.