Question regarding process for complex external/ contribution

[Nathaniel Husted]

I've currently been working on a port of the linux security software
Audit for the Android platform. I was wondering if there was a process
for contributing this to the external branch of the AOSP? I dug around
source.andorid.com and did not find any particulars regarding full
project contributions.


This project has a number of ancillary dependencies as well: 1) It
requires that Google add the audit.h to the parsed headers for bionic;
2) Google patch the Android specific kernel patches for ARM audit
support until they switch to Linux 3.3 and above(where my patch was
mainlined); 3) Google enable CONFIG_AUDIT and CONFIG_AUDITSYSCALL by
default in the kernel pre-builts. In regards to item 1, I currently
have the header file in the local project. This is by no means a final
solution but a stop-gap given my attempts to use the kernel header
parser script in AOSP have all led to failure. In regards to item 2, I
can provide back patches for Maguro and Goldfish (I assume I must
submit these to the android-kernel mailing list?). Is there any
process for making items 1 through 3 happen? Any guidance in this
whole process would be much appreciated.

Cheers,
Nathaniel Husted

[Jean-Baptiste Queru]

For anything out of the ordinary (like what you're proposing), the
process is "ask android-contrib". So far, so good :)

On the subject of creating the external/ project, besides getting an
approval on the principle of this change, we'll need to know where the
upstream code lives, how it's licensed, and the plan to handle both
the upstream copy and the Android copy.

#1 starts by updating the Android copy of the relevant linux kernel
header(s) in external/kernel-headers. You'll want to reference the
exact commit SHA-1 from which you copied those files from the kernel
tree. Once that's approved, the stripped variant used in bionic can be
re-generated.

#2 will involve some backporting indeed. Let's start with grouper
(Nexus 7, the newest device) and work backward from there. I'm not
sure that we'll strictly need this in goldfish 2.6.29, especially as
there's some work going on to move goldfish to 3.4. Uploads go through
the AOSP Gerrit as well.

#3 is very similar to #2, it's indeed just a case of uploading the
matching contributions.

JBQ

> --
>
>
>



--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Nathaniel Husted]

The original code for Audit itself is housed at
http://svn.fedorahosted.org/svn/audit (website for project:
https://people.redhat.com/sgrubb/audit/). My modifications (perhaps
even a fork at this point) are housed at
https://github.com/nwhusted/AuditdAndroid. The original code itself is
GPL V2. I'm aware this might cause issues with integration but wasn't
sure if there were a different set of license rules for the the
external projects.

A few questions for as I work through elements #1 through #3. In
reference to 1: I assume it would be wise to grab the kernel header
from the Nexus 7 kernel repository as that will be the target for #2.
In reference to 2: I do not have a Nexus 7 device to test the patch
on, however, it is relatively simple enough to be "obviously" correct
and can be compared against two tested and working patches. Would this
be an acceptable situation? In terms of on-device testing, all my
testing has occurred on the Galaxy Nexus.

Cheers,
Nathaniel

> --
>
>
>

[Dario Laverde]

Hi Nathaniel,

Does this security audit contribution overlap SE Linux for Android in anyway? The reason I ask is that I recall a presentation http://video.linux.com/videos/the-case-for-security-enhanced-se-android that mentions that initial SE Android contributions have been submitted to AOSP.

Does anyone here know what the status of SE Android contributions to AOSP are? 

http://selinuxproject.org/page/SEAndroid

thanks,

Dario

--

[Nathaniel Husted]

Dario, not exactly, no. The Audit subsystem in the Linux kernel can
multiplex SE Linux events in to its feed, however. The Audit subsystem
itself just allows for file system, system call, SE Linux, and
information from other kernel subsystems to be stored and send to
userland from one location. The benefit being the system has been
around for a very long time, is widely used, and has been optimized to
provide limited overhead. Eric Paris and Steve Grubb, from Redhat, are
the two primary maintainers for Audit.

Cheers,
Nathaniel Husted

> --
>
>
>

[Stephen Smalley]

On Mon, 2012-08-20 at 13:44 -0400, Dario Laverde wrote:

> Does this security audit contribution overlap SE Linux for Android in
> anyway? The reason I ask is that I recall a presentation
> http://video.linux.com/videos/the-case-for-security-enhanced-se-android that mentions that initial SE Android contributions have been submitted to AOSP.

No, they don't overlap (but improved Android audit support could be
helpful for SE Android).

> Does anyone here know what the status of SE Android contributions to
> AOSP are?
> http://selinuxproject.org/page/SEAndroid

Most of our changes have been merged into AOSP master. I'll be giving a
talk at LinuxCon next week with an update, and those slides should be
generally available shortly thereafter. Although you can see for
yourself just by watching our changes in gerrit or following our
periodic updates on selinux list,
http://marc.info/?l=selinux&m=134505067025021&w=2

--
Stephen Smalley
National Security Agency

[Jean-Baptiste Queru]

GPL is definitely a major issue.

Here's how things typically go w.r.t. GPL externals, not necessarily in order:
-Is the GPL code written in C or C++?
-Is there an Apache/MIT/BSD alternative to the GPL code?
-Can we live without the feature that requires the GPL code?
-Can the feature work without the GPL code?
-Can we re-license the GPL code?
-Can we re-implement the GPL code?
-Does the GPL code build on top of the NDK?

#1: it's best to get the kernel header from upstream. If that's not an
option, from one of the trees in kernel/common (android-3.0 or
android-3.4).

#2: that's really going to be a question for the kernel team.

JBQ

[Nathaniel Husted]

The GPL code (auditd, auditctl, etc.) is written in C. As after as I
know there are no alternatives under a different license. I'm unsure
of the legalities of re-licensing the GPL code, and because of this, I
will operate under the cautious assumption that we cannot.

The GPL code is userland code that provides and interface to the
kernel-land daemon (kauditd). It contains the userland API's to
interface with kernel via a Netlink socket. The code that issues #1,
#2, and #3 refer to will provide the foundations that the GPL code
will interact with. The userland audit functionality can be rewritten
with a more Android appropriate license as, primarily, it only needs
to transfer data from the Netlink socket and provide it to userland.
In the mean time the GPL code can be built on top of the NDK and I
have a set of instructions that outlines how to do this. It could
continue to be distributed via a third-party repository. As long as
the code is in place in the kernel, the executables built with the NDK
can be transferred to a device and run.

Cheers,
Nathaniel Husted

> --
>
>
>

[Jean-Baptiste Queru]

Thanks for looking into it.

If no non-GPL alternative can be found, this seems to fall into the
category where it's manageable (specifically, C code buildable with
the NDK)

If the engineers who'd maintain that code within Android tell me this
is a desirable feature to have and that there's indeed no non-GPL
alternative, we'll go with it.

JBQ