seandroid and policy version

seandroid and policy version

[Joshua Brindle]

I was looking at this:
<https://android-review.googlesource.com/#/c/36321/4/init/init.c>

and remembered that years ago we had a discussion about the .policyver 
filename syntax. I kind of get it for SELinux machines where there is 
managed policy and could be multiple policies on the system but since 
SEAndroid is targeting non-device managed policies, it adds extra code 
to search for the right extension and you can tell what version the 
policy is as soon as you open it, why not ditch the suffix?

--
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.

Re: seandroid and policy version

[Stephen Smalley]

On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
> I was looking at this:
> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
> 
> and remembered that years ago we had a discussion about the .policyver 
> filename syntax. I kind of get it for SELinux machines where there is 
> managed policy and could be multiple policies on the system but since 
> SEAndroid is targeting non-device managed policies, it adds extra code 
> to search for the right extension and you can tell what version the 
> policy is as soon as you open it, why not ditch the suffix?

First, that patch doesn't introduce the use of the version suffix
(that's in the already merged code); it just preserves it in the new
logic for reloading policy at runtime.

I'm open to removing the use of the policy version suffix in a follow-on
patch, although that would need to be coordinated across sepolicy and
system/core.  But the current code is consistent with existing practice
in Linux distributions (so follows principle of least surprise) and it
allows for different versions to be installed simultaneously (thereby
supporting booting multiple kernels).  Also, we don't have libsepol on
the device so we cannot in fact determine the version when we open it
there presently.  So I'm not convinced we should remove the suffix.

-- 
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.

Re: seandroid and policy version

[Joshua Brindle]

Stephen Smalley wrote:
> On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
>> I was looking at this:
>> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
>>
>> and remembered that years ago we had a discussion about the .policyver
>> filename syntax. I kind of get it for SELinux machines where there is
>> managed policy and could be multiple policies on the system but since
>> SEAndroid is targeting non-device managed policies, it adds extra code
>> to search for the right extension and you can tell what version the
>> policy is as soon as you open it, why not ditch the suffix?
>
> First, that patch doesn't introduce the use of the version suffix
> (that's in the already merged code); it just preserves it in the new
> logic for reloading policy at runtime.

I know, it just reminded me that I wanted to mention it :)

>
> I'm open to removing the use of the policy version suffix in a follow-on
> patch, although that would need to be coordinated across sepolicy and
> system/core.  But the current code is consistent with existing practice
> in Linux distributions (so follows principle of least surprise) and it

 From what I can tell most people doing anything with SEAndroid have never been 
exposed to SELinux so it probably is surprising to them that the file extension 
would change version to version.

> allows for different versions to be installed simultaneously (thereby
> supporting booting multiple kernels).  Also, we don't have libsepol on

I don't think this will ever be an issue on mobile devices (and I don't think it 
ever was an issue on real machines, more likely that stale policies were being 
enforced if there was some kernel or library change)

> the device so we cannot in fact determine the version when we open it
> there presently.  So I'm not convinced we should remove the suffix.

We don't need libsepol, just read the first few bytes, a la file.

--
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.

Re: seandroid and policy version

[Stephen Smalley]

On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
> >> I was looking at this:
> >> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
> >>
> >> and remembered that years ago we had a discussion about the .policyver
> >> filename syntax. I kind of get it for SELinux machines where there is
> >> managed policy and could be multiple policies on the system but since
> >> SEAndroid is targeting non-device managed policies, it adds extra code
> >> to search for the right extension and you can tell what version the
> >> policy is as soon as you open it, why not ditch the suffix?
> >
> > First, that patch doesn't introduce the use of the version suffix
> > (that's in the already merged code); it just preserves it in the new
> > logic for reloading policy at runtime.
> 
> I know, it just reminded me that I wanted to mention it :)
> 
> >
> > I'm open to removing the use of the policy version suffix in a follow-on
> > patch, although that would need to be coordinated across sepolicy and
> > system/core.  But the current code is consistent with existing practice
> > in Linux distributions (so follows principle of least surprise) and it
> 
>  From what I can tell most people doing anything with SEAndroid have never been 
> exposed to SELinux so it probably is surprising to them that the file extension 
> would change version to version.
> 
> > allows for different versions to be installed simultaneously (thereby
> > supporting booting multiple kernels).  Also, we don't have libsepol on
> 
> I don't think this will ever be an issue on mobile devices (and I don't think it 
> ever was an issue on real machines, more likely that stale policies were being 
> enforced if there was some kernel or library change)
> 
> > the device so we cannot in fact determine the version when we open it
> > there presently.  So I'm not convinced we should remove the suffix.
> 
> We don't need libsepol, just read the first few bytes, a la file.

We need libsepol at least if we want to support automatic downgrading of
the policy to a version supported by the kernel.  So unless we think we
can guarantee that Android userspace + kernel are always updated in
lock-step and one will never want to support multiple kernels, it seems
a bit inflexible to drop the versioning.

-- 
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.

Re: seandroid and policy version

[Stephen Smalley]

On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
> On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
> > >> I was looking at this:
> > >> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
> > >>
> > >> and remembered that years ago we had a discussion about the .policyver
> > >> filename syntax. I kind of get it for SELinux machines where there is
> > >> managed policy and could be multiple policies on the system but since
> > >> SEAndroid is targeting non-device managed policies, it adds extra code
> > >> to search for the right extension and you can tell what version the
> > >> policy is as soon as you open it, why not ditch the suffix?
> > >
> > > First, that patch doesn't introduce the use of the version suffix
> > > (that's in the already merged code); it just preserves it in the new
> > > logic for reloading policy at runtime.
> > 
> > I know, it just reminded me that I wanted to mention it :)
> > 
> > >
> > > I'm open to removing the use of the policy version suffix in a follow-on
> > > patch, although that would need to be coordinated across sepolicy and
> > > system/core.  But the current code is consistent with existing practice
> > > in Linux distributions (so follows principle of least surprise) and it
> > 
> >  From what I can tell most people doing anything with SEAndroid have never been 
> > exposed to SELinux so it probably is surprising to them that the file extension 
> > would change version to version.
> > 
> > > allows for different versions to be installed simultaneously (thereby
> > > supporting booting multiple kernels).  Also, we don't have libsepol on
> > 
> > I don't think this will ever be an issue on mobile devices (and I don't think it 
> > ever was an issue on real machines, more likely that stale policies were being 
> > enforced if there was some kernel or library change)
> > 
> > > the device so we cannot in fact determine the version when we open it
> > > there presently.  So I'm not convinced we should remove the suffix.
> > 
> > We don't need libsepol, just read the first few bytes, a la file.
> 
> We need libsepol at least if we want to support automatic downgrading of
> the policy to a version supported by the kernel.  So unless we think we
> can guarantee that Android userspace + kernel are always updated in
> lock-step and one will never want to support multiple kernels, it seems
> a bit inflexible to drop the versioning.

So this issue has come up again in the context of implementing device
admin APIs and a sample device admin app.  The device admin API
implementation in the system_server needs to know how to name the file
it creates under /data/system for the kernel policy, but it has no way
to determine the actual policy version of the supplied policy.  So it
doesn't know what suffix to use.  Options:
- Get rid of the version suffix altogether, or at least for the sepolicy
file under /data/system.
- Have the system_server parse the header of the policy image to
determine the policy version, and use that as the suffix.

Thoughts?

-- 
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.

Re: seandroid and policy version

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
<snip>
> So this issue has come up again in the context of implementing device
> admin APIs and a sample device admin app.  The device admin API
> implementation in the system_server needs to know how to name the file
> it creates under /data/system for the kernel policy, but it has no way
> to determine the actual policy version of the supplied policy.  So it
> doesn't know what suffix to use.  Options:
> - Get rid of the version suffix altogether, or at least for the sepolicy
> file under /data/system.
> - Have the system_server parse the header of the policy image to
> determine the policy version, and use that as the suffix.
>
> Thoughts?
>

Can the MDM server not provide the device admin API with the correct 
filename to use? How are you feeding the policy to the API?

I'm a fan of dropping the extension altogether but I'm just trying to 
understand the issue. I'd hope that the system_server wouldn't directly 
try to parse the image, hopefully at least a library would be used.

--
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.

Re: seandroid and policy version

[Stephen Smalley]

On Tue, 2012-09-18 at 13:40 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
> <snip>
> > So this issue has come up again in the context of implementing device
> > admin APIs and a sample device admin app.  The device admin API
> > implementation in the system_server needs to know how to name the file
> > it creates under /data/system for the kernel policy, but it has no way
> > to determine the actual policy version of the supplied policy.  So it
> > doesn't know what suffix to use.  Options:
> > - Get rid of the version suffix altogether, or at least for the sepolicy
> > file under /data/system.
> > - Have the system_server parse the header of the policy image to
> > determine the policy version, and use that as the suffix.
> >
> > Thoughts?
> >
> 
> Can the MDM server not provide the device admin API with the correct 
> filename to use? How are you feeding the policy to the API?

At the moment it is being passed directly as a byte array (similar to
security_load_policy).  Passing by pathname would require that the
system_server have read/search access to a private file created by the
device admin app, and passing by open fd would require that the device
admin app first write the policy image to local storage before passing
it to the system_server.  So passing it directly seems preferable.

> I'm a fan of dropping the extension altogether but I'm just trying to 
> understand the issue. I'd hope that the system_server wouldn't directly 
> try to parse the image, hopefully at least a library would be used.

I expect we'd add a function to the Android libselinux for this purpose,
since libsepol isn't available on the device.

-- 
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.

Re: seandroid and policy version

[William Roberts]

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

How hard is it to parse the header, is it a simple fixed with field?

I could go either way on this, I like have the version number in the file
name myself.

On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
> > On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle wrote:
> > > Stephen Smalley wrote:
> > > > On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
> > > >> I was looking at this:
> > > >> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
> > > >>
> > > >> and remembered that years ago we had a discussion about the
> .policyver
> > > >> filename syntax. I kind of get it for SELinux machines where there
> is
> > > >> managed policy and could be multiple policies on the system but
> since
> > > >> SEAndroid is targeting non-device managed policies, it adds extra
> code
> > > >> to search for the right extension and you can tell what version the
> > > >> policy is as soon as you open it, why not ditch the suffix?
> > > >
> > > > First, that patch doesn't introduce the use of the version suffix
> > > > (that's in the already merged code); it just preserves it in the new
> > > > logic for reloading policy at runtime.
> > >
> > > I know, it just reminded me that I wanted to mention it :)
> > >
> > > >
> > > > I'm open to removing the use of the policy version suffix in a
> follow-on
> > > > patch, although that would need to be coordinated across sepolicy and
> > > > system/core.  But the current code is consistent with existing
> practice
> > > > in Linux distributions (so follows principle of least surprise) and
> it
> > >
> > >  From what I can tell most people doing anything with SEAndroid have
> never been
> > > exposed to SELinux so it probably is surprising to them that the file
> extension
> > > would change version to version.
> > >
> > > > allows for different versions to be installed simultaneously (thereby
> > > > supporting booting multiple kernels).  Also, we don't have libsepol
> on
> > >
> > > I don't think this will ever be an issue on mobile devices (and I
> don't think it
> > > ever was an issue on real machines, more likely that stale policies
> were being
> > > enforced if there was some kernel or library change)
> > >
> > > > the device so we cannot in fact determine the version when we open it
> > > > there presently.  So I'm not convinced we should remove the suffix.
> > >
> > > We don't need libsepol, just read the first few bytes, a la file.
> >
> > We need libsepol at least if we want to support automatic downgrading of
> > the policy to a version supported by the kernel.  So unless we think we
> > can guarantee that Android userspace + kernel are always updated in
> > lock-step and one will never want to support multiple kernels, it seems
> > a bit inflexible to drop the versioning.
>
> So this issue has come up again in the context of implementing device
> admin APIs and a sample device admin app.  The device admin API
> implementation in the system_server needs to know how to name the file
> it creates under /data/system for the kernel policy, but it has no way
> to determine the actual policy version of the supplied policy.  So it
> doesn't know what suffix to use.  Options:
> - Get rid of the version suffix altogether, or at least for the sepolicy
> file under /data/system.
> - Have the system_server parse the header of the policy image to
> determine the policy version, and use that as the suffix.
>
> Thoughts?
>
> --
> Stephen Smalley
> National Security Agency
>
>


-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[Stephen Smalley]

On Tue, 2012-09-18 at 10:46 -0700, William Roberts wrote:
> How hard is it to parse the header, is it a simple fixed with field?
> 
> 
> I could go either way on this, I like have the version number in the
> file name myself.

See the beginning of policydb_read() in security/selinux/ss/policydb.c.
Fairly straightforward, especially as we can presume that it is a
SELinux kernel policy.  We would just read and check the magic number,
skip the fixed string identifier, and read the version number.

-- 
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.

Re: seandroid and policy version

[William Roberts]

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

Actually on second thought, lets ditch the version. Either your have a
supported version or not, and if you don't have a supported
version you've done something very wrong, and can extract dmesg and use
libsepol on the host to solve your problem. I would imagine dmesg would
have "cannot load policy error" and libsepol on the host could tell your
version number.

Bill

On Tue, Sep 18, 2012 at 10:46 AM, William Roberts
<bill.c.roberts@gmail.com>wrote:

> How hard is it to parse the header, is it a simple fixed with field?
>
> I could go either way on this, I like have the version number in the file
> name myself.
>
>
> On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley <sds@tycho.nsa.gov>wrote:
>
>> On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
>> > On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle wrote:
>> > > Stephen Smalley wrote:
>> > > > On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
>> > > >> I was looking at this:
>> > > >> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
>> > > >>
>> > > >> and remembered that years ago we had a discussion about the
>> .policyver
>> > > >> filename syntax. I kind of get it for SELinux machines where there
>> is
>> > > >> managed policy and could be multiple policies on the system but
>> since
>> > > >> SEAndroid is targeting non-device managed policies, it adds extra
>> code
>> > > >> to search for the right extension and you can tell what version the
>> > > >> policy is as soon as you open it, why not ditch the suffix?
>> > > >
>> > > > First, that patch doesn't introduce the use of the version suffix
>> > > > (that's in the already merged code); it just preserves it in the new
>> > > > logic for reloading policy at runtime.
>> > >
>> > > I know, it just reminded me that I wanted to mention it :)
>> > >
>> > > >
>> > > > I'm open to removing the use of the policy version suffix in a
>> follow-on
>> > > > patch, although that would need to be coordinated across sepolicy
>> and
>> > > > system/core.  But the current code is consistent with existing
>> practice
>> > > > in Linux distributions (so follows principle of least surprise) and
>> it
>> > >
>> > >  From what I can tell most people doing anything with SEAndroid have
>> never been
>> > > exposed to SELinux so it probably is surprising to them that the file
>> extension
>> > > would change version to version.
>> > >
>> > > > allows for different versions to be installed simultaneously
>> (thereby
>> > > > supporting booting multiple kernels).  Also, we don't have libsepol
>> on
>> > >
>> > > I don't think this will ever be an issue on mobile devices (and I
>> don't think it
>> > > ever was an issue on real machines, more likely that stale policies
>> were being
>> > > enforced if there was some kernel or library change)
>> > >
>> > > > the device so we cannot in fact determine the version when we open
>> it
>> > > > there presently.  So I'm not convinced we should remove the suffix.
>> > >
>> > > We don't need libsepol, just read the first few bytes, a la file.
>> >
>> > We need libsepol at least if we want to support automatic downgrading of
>> > the policy to a version supported by the kernel.  So unless we think we
>> > can guarantee that Android userspace + kernel are always updated in
>> > lock-step and one will never want to support multiple kernels, it seems
>> > a bit inflexible to drop the versioning.
>>
>> So this issue has come up again in the context of implementing device
>> admin APIs and a sample device admin app.  The device admin API
>> implementation in the system_server needs to know how to name the file
>> it creates under /data/system for the kernel policy, but it has no way
>> to determine the actual policy version of the supplied policy.  So it
>> doesn't know what suffix to use.  Options:
>> - Get rid of the version suffix altogether, or at least for the sepolicy
>> file under /data/system.
>> - Have the system_server parse the header of the policy image to
>> determine the policy version, and use that as the suffix.
>>
>> Thoughts?
>>
>> --
>> Stephen Smalley
>> National Security Agency
>>
>>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
>


-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[Joshua Brindle]

Stephen Smalley wrote:
> On Tue, 2012-09-18 at 13:40 -0400, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
>> <snip>
>>> So this issue has come up again in the context of implementing device
>>> admin APIs and a sample device admin app.  The device admin API
>>> implementation in the system_server needs to know how to name the file
>>> it creates under /data/system for the kernel policy, but it has no way
>>> to determine the actual policy version of the supplied policy.  So it
>>> doesn't know what suffix to use.  Options:
>>> - Get rid of the version suffix altogether, or at least for the sepolicy
>>> file under /data/system.
>>> - Have the system_server parse the header of the policy image to
>>> determine the policy version, and use that as the suffix.
>>>
>>> Thoughts?
>>>
>> Can the MDM server not provide the device admin API with the correct
>> filename to use? How are you feeding the policy to the API?
>
> At the moment it is being passed directly as a byte array (similar to
> security_load_policy).  Passing by pathname would require that the
> system_server have read/search access to a private file created by the
> device admin app, and passing by open fd would require that the device
> admin app first write the policy image to local storage before passing
> it to the system_server.  So passing it directly seems preferable.
>

I assumed byte array but is the API going to basically be "here's your 
policy blob" and the system_server has to figure out what to do with it? 
I strongly believe that we will outgrow an API like that very quickly. 
MDM vendors want to do some interesting things and always doing it on 
the server side isn't going to be feasible I think (holding >10k SELinux 
policies in order to update them when new 
containers/apps/features/whatever are added is not ideal).


--
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.

Re: seandroid and policy version

[William Roberts]

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

I saw up above your passing the policy as a byte array.... Were on memory
constrained devices, what happens if the file is to big to be resident in
memory? Could we just pass a fd?


On Tue, Sep 18, 2012 at 10:54 AM, William Roberts
<bill.c.roberts@gmail.com>wrote:

> Actually on second thought, lets ditch the version. Either your have a
> supported version or not, and if you don't have a supported
> version you've done something very wrong, and can extract dmesg and use
> libsepol on the host to solve your problem. I would imagine dmesg would
> have "cannot load policy error" and libsepol on the host could tell your
> version number.
>
> Bill
>
>
> On Tue, Sep 18, 2012 at 10:46 AM, William Roberts <
> bill.c.roberts@gmail.com> wrote:
>
>> How hard is it to parse the header, is it a simple fixed with field?
>>
>> I could go either way on this, I like have the version number in the file
>> name myself.
>>
>>
>> On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley <sds@tycho.nsa.gov>wrote:
>>
>>> On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
>>> > On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle wrote:
>>> > > Stephen Smalley wrote:
>>> > > > On Tue, 2012-07-10 at 20:07 -0400, Joshua Brindle wrote:
>>> > > >> I was looking at this:
>>> > > >> <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
>>> > > >>
>>> > > >> and remembered that years ago we had a discussion about the
>>> .policyver
>>> > > >> filename syntax. I kind of get it for SELinux machines where
>>> there is
>>> > > >> managed policy and could be multiple policies on the system but
>>> since
>>> > > >> SEAndroid is targeting non-device managed policies, it adds extra
>>> code
>>> > > >> to search for the right extension and you can tell what version
>>> the
>>> > > >> policy is as soon as you open it, why not ditch the suffix?
>>> > > >
>>> > > > First, that patch doesn't introduce the use of the version suffix
>>> > > > (that's in the already merged code); it just preserves it in the
>>> new
>>> > > > logic for reloading policy at runtime.
>>> > >
>>> > > I know, it just reminded me that I wanted to mention it :)
>>> > >
>>> > > >
>>> > > > I'm open to removing the use of the policy version suffix in a
>>> follow-on
>>> > > > patch, although that would need to be coordinated across sepolicy
>>> and
>>> > > > system/core.  But the current code is consistent with existing
>>> practice
>>> > > > in Linux distributions (so follows principle of least surprise)
>>> and it
>>> > >
>>> > >  From what I can tell most people doing anything with SEAndroid have
>>> never been
>>> > > exposed to SELinux so it probably is surprising to them that the
>>> file extension
>>> > > would change version to version.
>>> > >
>>> > > > allows for different versions to be installed simultaneously
>>> (thereby
>>> > > > supporting booting multiple kernels).  Also, we don't have
>>> libsepol on
>>> > >
>>> > > I don't think this will ever be an issue on mobile devices (and I
>>> don't think it
>>> > > ever was an issue on real machines, more likely that stale policies
>>> were being
>>> > > enforced if there was some kernel or library change)
>>> > >
>>> > > > the device so we cannot in fact determine the version when we open
>>> it
>>> > > > there presently.  So I'm not convinced we should remove the suffix.
>>> > >
>>> > > We don't need libsepol, just read the first few bytes, a la file.
>>> >
>>> > We need libsepol at least if we want to support automatic downgrading
>>> of
>>> > the policy to a version supported by the kernel.  So unless we think we
>>> > can guarantee that Android userspace + kernel are always updated in
>>> > lock-step and one will never want to support multiple kernels, it seems
>>> > a bit inflexible to drop the versioning.
>>>
>>> So this issue has come up again in the context of implementing device
>>> admin APIs and a sample device admin app.  The device admin API
>>> implementation in the system_server needs to know how to name the file
>>> it creates under /data/system for the kernel policy, but it has no way
>>> to determine the actual policy version of the supplied policy.  So it
>>> doesn't know what suffix to use.  Options:
>>> - Get rid of the version suffix altogether, or at least for the sepolicy
>>> file under /data/system.
>>> - Have the system_server parse the header of the policy image to
>>> determine the policy version, and use that as the suffix.
>>>
>>> Thoughts?
>>>
>>> --
>>> Stephen Smalley
>>> National Security Agency
>>>
>>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>>
>>
>>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
>


-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[Stephen Smalley]

On Tue, 2012-09-18 at 10:57 -0700, William Roberts wrote:
> I saw up above your passing the policy as a byte array.... Were on
> memory constrained devices, what happens if the file is to big to be
> resident in memory? Could we just pass a fd?

We're talking about kernel policy, so it has to live within kernel
memory ultimately.  So if it is too big to be resident in userspace
memory, then I think you have other problems.

Passing by fd means that the device admin app has to first write it to a
private file on local storage.  So then you are requiring two copies to
local storage, one temporary copy written by the device admin app to a
private file and one final copy written by the system_server
to /data/system.

Willing to consider a different API, but not clear whether it is
beneficial overall to switch to passing by fd.

> On Tue, Sep 18, 2012 at 10:54 AM, William Roberts
> <bill.c.roberts@gmail.com> wrote:
>         Actually on second thought, lets ditch the version. Either
>         your have a supported version or not, and if you don't have a
>         supported version you've done something very wrong, and can
>         extract dmesg and use libsepol on the host to solve your
>         problem. I would imagine dmesg would have "cannot load policy
>         error" and libsepol on the host could tell your version
>         number. 
>         
>         
>         Bill
>         
>         
>         On Tue, Sep 18, 2012 at 10:46 AM, William Roberts
>         <bill.c.roberts@gmail.com> wrote:
>                 How hard is it to parse the header, is it a simple
>                 fixed with field?
>                 
>                 
>                 I could go either way on this, I like have the version
>                 number in the file name myself.
>                 
>                 
>                 On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley
>                 <sds@tycho.nsa.gov> wrote:
>                         On Wed, 2012-07-11 at 15:49 -0400, Stephen
>                         Smalley wrote:
>                         > On Wed, 2012-07-11 at 15:45 -0400, Joshua
>                         Brindle wrote:
>                         > > Stephen Smalley wrote:
>                         > > > On Tue, 2012-07-10 at 20:07 -0400,
>                         Joshua Brindle wrote:
>                         > > >> I was looking at this:
>                         > > >>
>                         <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
>                         > > >>
>                         > > >> and remembered that years ago we had a
>                         discussion about the .policyver
>                         > > >> filename syntax. I kind of get it for
>                         SELinux machines where there is
>                         > > >> managed policy and could be multiple
>                         policies on the system but since
>                         > > >> SEAndroid is targeting non-device
>                         managed policies, it adds extra code
>                         > > >> to search for the right extension and
>                         you can tell what version the
>                         > > >> policy is as soon as you open it, why
>                         not ditch the suffix?
>                         > > >
>                         > > > First, that patch doesn't introduce the
>                         use of the version suffix
>                         > > > (that's in the already merged code); it
>                         just preserves it in the new
>                         > > > logic for reloading policy at runtime.
>                         > >
>                         > > I know, it just reminded me that I wanted
>                         to mention it :)
>                         > >
>                         > > >
>                         > > > I'm open to removing the use of the
>                         policy version suffix in a follow-on
>                         > > > patch, although that would need to be
>                         coordinated across sepolicy and
>                         > > > system/core.  But the current code is
>                         consistent with existing practice
>                         > > > in Linux distributions (so follows
>                         principle of least surprise) and it
>                         > >
>                         > >  From what I can tell most people doing
>                         anything with SEAndroid have never been
>                         > > exposed to SELinux so it probably is
>                         surprising to them that the file extension
>                         > > would change version to version.
>                         > >
>                         > > > allows for different versions to be
>                         installed simultaneously (thereby
>                         > > > supporting booting multiple kernels).
>                          Also, we don't have libsepol on
>                         > >
>                         > > I don't think this will ever be an issue
>                         on mobile devices (and I don't think it
>                         > > ever was an issue on real machines, more
>                         likely that stale policies were being
>                         > > enforced if there was some kernel or
>                         library change)
>                         > >
>                         > > > the device so we cannot in fact
>                         determine the version when we open it
>                         > > > there presently.  So I'm not convinced
>                         we should remove the suffix.
>                         > >
>                         > > We don't need libsepol, just read the
>                         first few bytes, a la file.
>                         >
>                         > We need libsepol at least if we want to
>                         support automatic downgrading of
>                         > the policy to a version supported by the
>                         kernel.  So unless we think we
>                         > can guarantee that Android userspace +
>                         kernel are always updated in
>                         > lock-step and one will never want to support
>                         multiple kernels, it seems
>                         > a bit inflexible to drop the versioning.
>                         
>                         
>                         So this issue has come up again in the context
>                         of implementing device
>                         admin APIs and a sample device admin app.  The
>                         device admin API
>                         implementation in the system_server needs to
>                         know how to name the file
>                         it creates under /data/system for the kernel
>                         policy, but it has no way
>                         to determine the actual policy version of the
>                         supplied policy.  So it
>                         doesn't know what suffix to use.  Options:
>                         - Get rid of the version suffix altogether, or
>                         at least for the sepolicy
>                         file under /data/system.
>                         - Have the system_server parse the header of
>                         the policy image to
>                         determine the policy version, and use that as
>                         the suffix.
>                         
>                         Thoughts?
>                         
>                         --
>                         Stephen Smalley
>                         National Security Agency
>                         
>                         
>                 
>                 
>                 
>                 
>                 -- 
>                 Respectfully,
>                 
>                 William C Roberts
>                 
>                 
>                 
>         
>         
>         
>         
>         -- 
>         Respectfully,
>         
>         William C Roberts
>         
>         
>         
> 
> 
> 
> 
> -- 
> Respectfully,
> 
> William C Roberts
> 
> 
> 

-- 
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.

Re: seandroid and policy version

[Stephen Smalley]

On Tue, 2012-09-18 at 10:54 -0700, William Roberts wrote:
> Actually on second thought, lets ditch the version. Either your have a
> supported version or not, and if you don't have a supported version
> you've done something very wrong, and can extract dmesg and use
> libsepol on the host to solve your problem. I would imagine dmesg
> would have "cannot load policy error" and libsepol on the host could
> tell your version number. 

The reason for the version number suffix is so that you can have
multiple versions installed simultaneously for different kernels,
allowing you to install a new version for a new kernel yet still back
out to the old version/old kernel if necessary.

If we do drop the version suffix, do we do it only for
the /data/system/sepolicy or also for /sepolicy?  Requires a coordinated
change across external/sepolicy and external/libselinux (and for 4.0.4,
system/core since it still has the old policy loading logic directly
within init).

Also, do we continue to force the policy version to 24 in
external/sepolicy Android.mk or let it go with whatever checkpolicy
supports.  We were capping it at policy.24 because that is the least
common denominator for all of the AOSP kernels (going back to the
emulator kernel), and because that was the latest version supported by
Ubuntu 10.04 (but that doesn't matter now that there is a copy of
checkpolicy in AOSP, which we might want to get updated btw).

> On Tue, Sep 18, 2012 at 10:46 AM, William Roberts
> <bill.c.roberts@gmail.com> wrote:
>         How hard is it to parse the header, is it a simple fixed with
>         field?
>         
>         
>         I could go either way on this, I like have the version number
>         in the file name myself.
>         
>         
>         On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley
>         <sds@tycho.nsa.gov> wrote:
>                 On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley
>                 wrote:
>                 > On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle
>                 wrote:
>                 > > Stephen Smalley wrote:
>                 > > > On Tue, 2012-07-10 at 20:07 -0400, Joshua
>                 Brindle wrote:
>                 > > >> I was looking at this:
>                 > > >>
>                 <https://android-review.googlesource.com/#/c/36321/4/init/init.c>
>                 > > >>
>                 > > >> and remembered that years ago we had a
>                 discussion about the .policyver
>                 > > >> filename syntax. I kind of get it for SELinux
>                 machines where there is
>                 > > >> managed policy and could be multiple policies
>                 on the system but since
>                 > > >> SEAndroid is targeting non-device managed
>                 policies, it adds extra code
>                 > > >> to search for the right extension and you can
>                 tell what version the
>                 > > >> policy is as soon as you open it, why not ditch
>                 the suffix?
>                 > > >
>                 > > > First, that patch doesn't introduce the use of
>                 the version suffix
>                 > > > (that's in the already merged code); it just
>                 preserves it in the new
>                 > > > logic for reloading policy at runtime.
>                 > >
>                 > > I know, it just reminded me that I wanted to
>                 mention it :)
>                 > >
>                 > > >
>                 > > > I'm open to removing the use of the policy
>                 version suffix in a follow-on
>                 > > > patch, although that would need to be
>                 coordinated across sepolicy and
>                 > > > system/core.  But the current code is consistent
>                 with existing practice
>                 > > > in Linux distributions (so follows principle of
>                 least surprise) and it
>                 > >
>                 > >  From what I can tell most people doing anything
>                 with SEAndroid have never been
>                 > > exposed to SELinux so it probably is surprising to
>                 them that the file extension
>                 > > would change version to version.
>                 > >
>                 > > > allows for different versions to be installed
>                 simultaneously (thereby
>                 > > > supporting booting multiple kernels).  Also, we
>                 don't have libsepol on
>                 > >
>                 > > I don't think this will ever be an issue on mobile
>                 devices (and I don't think it
>                 > > ever was an issue on real machines, more likely
>                 that stale policies were being
>                 > > enforced if there was some kernel or library
>                 change)
>                 > >
>                 > > > the device so we cannot in fact determine the
>                 version when we open it
>                 > > > there presently.  So I'm not convinced we should
>                 remove the suffix.
>                 > >
>                 > > We don't need libsepol, just read the first few
>                 bytes, a la file.
>                 >
>                 > We need libsepol at least if we want to support
>                 automatic downgrading of
>                 > the policy to a version supported by the kernel.  So
>                 unless we think we
>                 > can guarantee that Android userspace + kernel are
>                 always updated in
>                 > lock-step and one will never want to support
>                 multiple kernels, it seems
>                 > a bit inflexible to drop the versioning.
>                 
>                 
>                 So this issue has come up again in the context of
>                 implementing device
>                 admin APIs and a sample device admin app.  The device
>                 admin API
>                 implementation in the system_server needs to know how
>                 to name the file
>                 it creates under /data/system for the kernel policy,
>                 but it has no way
>                 to determine the actual policy version of the supplied
>                 policy.  So it
>                 doesn't know what suffix to use.  Options:
>                 - Get rid of the version suffix altogether, or at
>                 least for the sepolicy
>                 file under /data/system.
>                 - Have the system_server parse the header of the
>                 policy image to
>                 determine the policy version, and use that as the
>                 suffix.
>                 
>                 Thoughts?
>                 
>                 --
>                 Stephen Smalley
>                 National Security Agency
>                 
>                 
>         
>         
>         
>         
>         -- 
>         Respectfully,
>         
>         William C Roberts
>         
>         
>         
> 
> 
> 
> 
> -- 
> Respectfully,
> 
> William C Roberts
> 
> 
> 

-- 
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.

Re: seandroid and policy version

[Stephen Smalley]

On Tue, 2012-09-18 at 13:56 -0400, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Tue, 2012-09-18 at 13:40 -0400, Joshua Brindle wrote:
> >> Stephen Smalley wrote:
> >>> On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley wrote:
> >> <snip>
> >>> So this issue has come up again in the context of implementing device
> >>> admin APIs and a sample device admin app.  The device admin API
> >>> implementation in the system_server needs to know how to name the file
> >>> it creates under /data/system for the kernel policy, but it has no way
> >>> to determine the actual policy version of the supplied policy.  So it
> >>> doesn't know what suffix to use.  Options:
> >>> - Get rid of the version suffix altogether, or at least for the sepolicy
> >>> file under /data/system.
> >>> - Have the system_server parse the header of the policy image to
> >>> determine the policy version, and use that as the suffix.
> >>>
> >>> Thoughts?
> >>>
> >> Can the MDM server not provide the device admin API with the correct
> >> filename to use? How are you feeding the policy to the API?
> >
> > At the moment it is being passed directly as a byte array (similar to
> > security_load_policy).  Passing by pathname would require that the
> > system_server have read/search access to a private file created by the
> > device admin app, and passing by open fd would require that the device
> > admin app first write the policy image to local storage before passing
> > it to the system_server.  So passing it directly seems preferable.
> >
> 
> I assumed byte array but is the API going to basically be "here's your 
> policy blob" and the system_server has to figure out what to do with it? 
> I strongly believe that we will outgrow an API like that very quickly. 
> MDM vendors want to do some interesting things and always doing it on 
> the server side isn't going to be feasible I think (holding >10k SELinux 
> policies in order to update them when new 
> containers/apps/features/whatever are added is not ideal).

Well, first, it is intended as a starting point, so it doesn't exclude
providing finer-grained APIs in the future.  Second, as we don't
presently have any way to manipulate policy on the device in any other
way than setting policy booleans or completely replacing policy, there
isn't much point in providing such a finer-grained API until we have the
underlying support for it.

-- 
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.

Re: seandroid and policy version

[William Roberts]

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

Ahh yeah you are correct, it would have to be resident in kernel memory.
With that argument that api sounds sufficient.

Could we configure the policy version independent of the makefile. This way
oem's can control what version they want, maybe something like POLICYVERS
variable could be overridden too. I think we could just drop the version
suffix unless it gets us something that we may need in the future. If it
might be beneficial for unforeseen future growth, then we would keep it an
have system_server parse the first few bytes out for the version suffix.

On Tue, Sep 18, 2012 at 11:15 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Tue, 2012-09-18 at 10:54 -0700, William Roberts wrote:
> > Actually on second thought, lets ditch the version. Either your have a
> > supported version or not, and if you don't have a supported version
> > you've done something very wrong, and can extract dmesg and use
> > libsepol on the host to solve your problem. I would imagine dmesg
> > would have "cannot load policy error" and libsepol on the host could
> > tell your version number.
>
> The reason for the version number suffix is so that you can have
> multiple versions installed simultaneously for different kernels,
> allowing you to install a new version for a new kernel yet still back
> out to the old version/old kernel if necessary.
>
> If we do drop the version suffix, do we do it only for
> the /data/system/sepolicy or also for /sepolicy?  Requires a coordinated
> change across external/sepolicy and external/libselinux (and for 4.0.4,
> system/core since it still has the old policy loading logic directly
> within init).
>
> Also, do we continue to force the policy version to 24 in
> external/sepolicy Android.mk or let it go with whatever checkpolicy
> supports.  We were capping it at policy.24 because that is the least
> common denominator for all of the AOSP kernels (going back to the
> emulator kernel), and because that was the latest version supported by
> Ubuntu 10.04 (but that doesn't matter now that there is a copy of
> checkpolicy in AOSP, which we might want to get updated btw).
>
> > On Tue, Sep 18, 2012 at 10:46 AM, William Roberts
> > <bill.c.roberts@gmail.com> wrote:
> >         How hard is it to parse the header, is it a simple fixed with
> >         field?
> >
> >
> >         I could go either way on this, I like have the version number
> >         in the file name myself.
> >
> >
> >         On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley
> >         <sds@tycho.nsa.gov> wrote:
> >                 On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley
> >                 wrote:
> >                 > On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle
> >                 wrote:
> >                 > > Stephen Smalley wrote:
> >                 > > > On Tue, 2012-07-10 at 20:07 -0400, Joshua
> >                 Brindle wrote:
> >                 > > >> I was looking at this:
> >                 > > >>
> >                 <
> https://android-review.googlesource.com/#/c/36321/4/init/init.c>
> >                 > > >>
> >                 > > >> and remembered that years ago we had a
> >                 discussion about the .policyver
> >                 > > >> filename syntax. I kind of get it for SELinux
> >                 machines where there is
> >                 > > >> managed policy and could be multiple policies
> >                 on the system but since
> >                 > > >> SEAndroid is targeting non-device managed
> >                 policies, it adds extra code
> >                 > > >> to search for the right extension and you can
> >                 tell what version the
> >                 > > >> policy is as soon as you open it, why not ditch
> >                 the suffix?
> >                 > > >
> >                 > > > First, that patch doesn't introduce the use of
> >                 the version suffix
> >                 > > > (that's in the already merged code); it just
> >                 preserves it in the new
> >                 > > > logic for reloading policy at runtime.
> >                 > >
> >                 > > I know, it just reminded me that I wanted to
> >                 mention it :)
> >                 > >
> >                 > > >
> >                 > > > I'm open to removing the use of the policy
> >                 version suffix in a follow-on
> >                 > > > patch, although that would need to be
> >                 coordinated across sepolicy and
> >                 > > > system/core.  But the current code is consistent
> >                 with existing practice
> >                 > > > in Linux distributions (so follows principle of
> >                 least surprise) and it
> >                 > >
> >                 > >  From what I can tell most people doing anything
> >                 with SEAndroid have never been
> >                 > > exposed to SELinux so it probably is surprising to
> >                 them that the file extension
> >                 > > would change version to version.
> >                 > >
> >                 > > > allows for different versions to be installed
> >                 simultaneously (thereby
> >                 > > > supporting booting multiple kernels).  Also, we
> >                 don't have libsepol on
> >                 > >
> >                 > > I don't think this will ever be an issue on mobile
> >                 devices (and I don't think it
> >                 > > ever was an issue on real machines, more likely
> >                 that stale policies were being
> >                 > > enforced if there was some kernel or library
> >                 change)
> >                 > >
> >                 > > > the device so we cannot in fact determine the
> >                 version when we open it
> >                 > > > there presently.  So I'm not convinced we should
> >                 remove the suffix.
> >                 > >
> >                 > > We don't need libsepol, just read the first few
> >                 bytes, a la file.
> >                 >
> >                 > We need libsepol at least if we want to support
> >                 automatic downgrading of
> >                 > the policy to a version supported by the kernel.  So
> >                 unless we think we
> >                 > can guarantee that Android userspace + kernel are
> >                 always updated in
> >                 > lock-step and one will never want to support
> >                 multiple kernels, it seems
> >                 > a bit inflexible to drop the versioning.
> >
> >
> >                 So this issue has come up again in the context of
> >                 implementing device
> >                 admin APIs and a sample device admin app.  The device
> >                 admin API
> >                 implementation in the system_server needs to know how
> >                 to name the file
> >                 it creates under /data/system for the kernel policy,
> >                 but it has no way
> >                 to determine the actual policy version of the supplied
> >                 policy.  So it
> >                 doesn't know what suffix to use.  Options:
> >                 - Get rid of the version suffix altogether, or at
> >                 least for the sepolicy
> >                 file under /data/system.
> >                 - Have the system_server parse the header of the
> >                 policy image to
> >                 determine the policy version, and use that as the
> >                 suffix.
> >
> >                 Thoughts?
> >
> >                 --
> >                 Stephen Smalley
> >                 National Security Agency
> >
> >
> >
> >
> >
> >
> >         --
> >         Respectfully,
> >
> >         William C Roberts
> >
> >
> >
> >
> >
> >
> >
> > --
> > Respectfully,
> >
> > William C Roberts
> >
> >
> >
>
> --
> Stephen Smalley
> National Security Agency
>
>


-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[William Roberts]

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

Yes, I would imagine right now the api is pretty much reload policy, get
booleans /set boolean type of api.

On Tue, Sep 18, 2012 at 11:25 AM, William Roberts
<bill.c.roberts@gmail.com>wrote:

> Ahh yeah you are correct, it would have to be resident in kernel memory.
> With that argument that api sounds sufficient.
>
> Could we configure the policy version independent of the makefile. This
> way oem's can control what version they want, maybe something like
> POLICYVERS variable could be overridden too. I think we could just drop the
> version suffix unless it gets us something that we may need in the future.
> If it might be beneficial for unforeseen future growth, then we would keep
> it an have system_server parse the first few bytes out for the version
> suffix.
>
>
> On Tue, Sep 18, 2012 at 11:15 AM, Stephen Smalley <sds@tycho.nsa.gov>wrote:
>
>> On Tue, 2012-09-18 at 10:54 -0700, William Roberts wrote:
>> > Actually on second thought, lets ditch the version. Either your have a
>> > supported version or not, and if you don't have a supported version
>> > you've done something very wrong, and can extract dmesg and use
>> > libsepol on the host to solve your problem. I would imagine dmesg
>> > would have "cannot load policy error" and libsepol on the host could
>> > tell your version number.
>>
>> The reason for the version number suffix is so that you can have
>> multiple versions installed simultaneously for different kernels,
>> allowing you to install a new version for a new kernel yet still back
>> out to the old version/old kernel if necessary.
>>
>> If we do drop the version suffix, do we do it only for
>> the /data/system/sepolicy or also for /sepolicy?  Requires a coordinated
>> change across external/sepolicy and external/libselinux (and for 4.0.4,
>> system/core since it still has the old policy loading logic directly
>> within init).
>>
>> Also, do we continue to force the policy version to 24 in
>> external/sepolicy Android.mk or let it go with whatever checkpolicy
>> supports.  We were capping it at policy.24 because that is the least
>> common denominator for all of the AOSP kernels (going back to the
>> emulator kernel), and because that was the latest version supported by
>> Ubuntu 10.04 (but that doesn't matter now that there is a copy of
>> checkpolicy in AOSP, which we might want to get updated btw).
>>
>> > On Tue, Sep 18, 2012 at 10:46 AM, William Roberts
>> > <bill.c.roberts@gmail.com> wrote:
>> >         How hard is it to parse the header, is it a simple fixed with
>> >         field?
>> >
>> >
>> >         I could go either way on this, I like have the version number
>> >         in the file name myself.
>> >
>> >
>> >         On Tue, Sep 18, 2012 at 10:33 AM, Stephen Smalley
>> >         <sds@tycho.nsa.gov> wrote:
>> >                 On Wed, 2012-07-11 at 15:49 -0400, Stephen Smalley
>> >                 wrote:
>> >                 > On Wed, 2012-07-11 at 15:45 -0400, Joshua Brindle
>> >                 wrote:
>> >                 > > Stephen Smalley wrote:
>> >                 > > > On Tue, 2012-07-10 at 20:07 -0400, Joshua
>> >                 Brindle wrote:
>> >                 > > >> I was looking at this:
>> >                 > > >>
>> >                 <
>> https://android-review.googlesource.com/#/c/36321/4/init/init.c>
>> >                 > > >>
>> >                 > > >> and remembered that years ago we had a
>> >                 discussion about the .policyver
>> >                 > > >> filename syntax. I kind of get it for SELinux
>> >                 machines where there is
>> >                 > > >> managed policy and could be multiple policies
>> >                 on the system but since
>> >                 > > >> SEAndroid is targeting non-device managed
>> >                 policies, it adds extra code
>> >                 > > >> to search for the right extension and you can
>> >                 tell what version the
>> >                 > > >> policy is as soon as you open it, why not ditch
>> >                 the suffix?
>> >                 > > >
>> >                 > > > First, that patch doesn't introduce the use of
>> >                 the version suffix
>> >                 > > > (that's in the already merged code); it just
>> >                 preserves it in the new
>> >                 > > > logic for reloading policy at runtime.
>> >                 > >
>> >                 > > I know, it just reminded me that I wanted to
>> >                 mention it :)
>> >                 > >
>> >                 > > >
>> >                 > > > I'm open to removing the use of the policy
>> >                 version suffix in a follow-on
>> >                 > > > patch, although that would need to be
>> >                 coordinated across sepolicy and
>> >                 > > > system/core.  But the current code is consistent
>> >                 with existing practice
>> >                 > > > in Linux distributions (so follows principle of
>> >                 least surprise) and it
>> >                 > >
>> >                 > >  From what I can tell most people doing anything
>> >                 with SEAndroid have never been
>> >                 > > exposed to SELinux so it probably is surprising to
>> >                 them that the file extension
>> >                 > > would change version to version.
>> >                 > >
>> >                 > > > allows for different versions to be installed
>> >                 simultaneously (thereby
>> >                 > > > supporting booting multiple kernels).  Also, we
>> >                 don't have libsepol on
>> >                 > >
>> >                 > > I don't think this will ever be an issue on mobile
>> >                 devices (and I don't think it
>> >                 > > ever was an issue on real machines, more likely
>> >                 that stale policies were being
>> >                 > > enforced if there was some kernel or library
>> >                 change)
>> >                 > >
>> >                 > > > the device so we cannot in fact determine the
>> >                 version when we open it
>> >                 > > > there presently.  So I'm not convinced we should
>> >                 remove the suffix.
>> >                 > >
>> >                 > > We don't need libsepol, just read the first few
>> >                 bytes, a la file.
>> >                 >
>> >                 > We need libsepol at least if we want to support
>> >                 automatic downgrading of
>> >                 > the policy to a version supported by the kernel.  So
>> >                 unless we think we
>> >                 > can guarantee that Android userspace + kernel are
>> >                 always updated in
>> >                 > lock-step and one will never want to support
>> >                 multiple kernels, it seems
>> >                 > a bit inflexible to drop the versioning.
>> >
>> >
>> >                 So this issue has come up again in the context of
>> >                 implementing device
>> >                 admin APIs and a sample device admin app.  The device
>> >                 admin API
>> >                 implementation in the system_server needs to know how
>> >                 to name the file
>> >                 it creates under /data/system for the kernel policy,
>> >                 but it has no way
>> >                 to determine the actual policy version of the supplied
>> >                 policy.  So it
>> >                 doesn't know what suffix to use.  Options:
>> >                 - Get rid of the version suffix altogether, or at
>> >                 least for the sepolicy
>> >                 file under /data/system.
>> >                 - Have the system_server parse the header of the
>> >                 policy image to
>> >                 determine the policy version, and use that as the
>> >                 suffix.
>> >
>> >                 Thoughts?
>> >
>> >                 --
>> >                 Stephen Smalley
>> >                 National Security Agency
>> >
>> >
>> >
>> >
>> >
>> >
>> >         --
>> >         Respectfully,
>> >
>> >         William C Roberts
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Respectfully,
>> >
>> > William C Roberts
>> >
>> >
>> >
>>
>> --
>> Stephen Smalley
>> National Security Agency
>>
>>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>
>


-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[Stephen Smalley]

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

Attached are patches for libselinux and sepolicy to drop the policy
version suffix.  We still force generation of a version 24 policy by
default, although this can be overridden via make command-line or
environment setting (e.g. export POLICYVERS=26).  Does this seem sane?
Note that seandroid-4.0.4 requires changes to system/core as well, so
this only fixes it for master and 4.1.1.


-- 
Stephen Smalley
National Security Agency

[-- Attachment #2: libselinux-dropverssuffix.diff --]
[-- Type: text/x-patch, Size: 1351 bytes --]

diff --git a/src/android.c b/src/android.c
index ae3f624..af6c79c 100644
--- a/src/android.c
+++ b/src/android.c
@@ -36,7 +36,7 @@ static const struct selinux_opt seopts[] = {
 	{ SELABEL_OPT_PATH, "/file_contexts" },
 	{ 0, NULL } };
 
-static const char *const sepolicy_prefix[] = {
+static const char *const sepolicy_file[] = {
         "/data/system/sepolicy",
         "/sepolicy",
         0 };
@@ -671,29 +671,15 @@ struct selabel_handle* selinux_android_file_context_handle(void)
 int selinux_android_reload_policy(void)
 {
 	char path[PATH_MAX];
-	int fd = -1, rc, vers;
+	int fd = -1, rc;
 	struct stat sb;
 	void *map = NULL;
 	int i = 0;
 
-	vers = security_policyvers();
-	if (vers <= 0) {
-		selinux_log(SELINUX_ERROR, "SELinux:  Unable to read policy version\n");
-		return -1;
-	}
-	selinux_log(SELINUX_INFO, "SELinux:  Maximum supported policy version:  %d\n", vers);
-
-	while (fd < 0 && sepolicy_prefix[i]) {
-		snprintf(path, sizeof(path), "%s.%d",
-			sepolicy_prefix[i], vers);
+	while (fd < 0 && sepolicy_file[i]) {
+		snprintf(path, sizeof(path), "%s",
+			sepolicy_file[i]);
 		fd = open(path, O_RDONLY);
-
-		int max_vers = vers;
-		while (fd < 0 && errno == ENOENT && --max_vers) {
-			snprintf(path, sizeof(path), "%s.%d",
-				sepolicy_prefix[i], max_vers);
-			fd = open(path, O_RDONLY);
-		}
 		i++;
 	}
 	if (fd < 0) {

[-- Attachment #3: sepolicy-dropverssuffix.diff --]
[-- Type: text/x-patch, Size: 1223 bytes --]

diff --git a/Android.mk b/Android.mk
index 194dbf7..d3b21bb 100644
--- a/Android.mk
+++ b/Android.mk
@@ -9,7 +9,7 @@ include $(CLEAR_VARS)
 # SELinux policy version.
 # Must be <= /selinux/policyvers reported by the Android kernel.
 # Must be within the compatibility range reported by checkpolicy -V.
-POLICYVERS := 24
+POLICYVERS ?= 24
 
 MLS_SENS=1
 MLS_CATS=1024
@@ -31,7 +31,6 @@ include $(CLEAR_VARS)
 LOCAL_MODULE := sepolicy
 LOCAL_MODULE_CLASS := ETC
 LOCAL_MODULE_TAGS := optional
-LOCAL_MODULE_SUFFIX := .$(POLICYVERS)
 LOCAL_MODULE_PATH := $(TARGET_ROOT_OUT)
 
 include $(BUILD_SYSTEM)/base_rules.mk
@@ -79,9 +78,9 @@ $(seapp_contexts.tmp): $(LOCAL_PATH)/seapp_contexts $(LOCAL_POLICY_SC)
 	@mkdir -p $(dir $@)
 	$(hide) m4 -s $^ > $@
 
-$(LOCAL_BUILT_MODULE) : $(seapp_contexts.tmp) $(TARGET_ROOT_OUT)/sepolicy.$(POLICYVERS) $(HOST_OUT_EXECUTABLES)/checkseapp
+$(LOCAL_BUILT_MODULE) : $(seapp_contexts.tmp) $(TARGET_ROOT_OUT)/sepolicy $(HOST_OUT_EXECUTABLES)/checkseapp
 	@mkdir -p $(dir $@)
-	$(HOST_OUT_EXECUTABLES)/checkseapp -p $(TARGET_ROOT_OUT)/sepolicy.24 -o $@ $<
+	$(HOST_OUT_EXECUTABLES)/checkseapp -p $(TARGET_ROOT_OUT)/sepolicy -o $@ $<
 
 seapp_contexts.tmp :=
 ##################################

Re: seandroid and policy version

[William Roberts]

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

Those look fine with me.

Only a few will export the POLICYVERS, but it would be nice to override in
the of chance you need to. The biggest thing will be to worry about AOSP
but make it easy to support oem's so they can configure it without having
to edit the base code.

Bill

On Tue, Sep 18, 2012 at 11:52 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> Attached are patches for libselinux and sepolicy to drop the policy
> version suffix.  We still force generation of a version 24 policy by
> default, although this can be overridden via make command-line or
> environment setting (e.g. export POLICYVERS=26).  Does this seem sane?
> Note that seandroid-4.0.4 requires changes to system/core as well, so
> this only fixes it for master and 4.1.1.
>
>
> --
> Stephen Smalley
> National Security Agency
>



-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[Joshua Brindle]

Stephen Smalley wrote:
> Attached are patches for libselinux and sepolicy to drop the policy
> version suffix. We still force generation of a version 24 policy by
> default, although this can be overridden via make command-line or
> environment setting (e.g. export POLICYVERS=26). Does this seem sane?
> Note that seandroid-4.0.4 requires changes to system/core as well, so
> this only fixes it for master and 4.1.1.
>

Looks fine to me. Any chance that POLICYVERS could be set in a device 
makefile? Since you'll know what kernel you are using to build a 
particular device it would be nice to set it there and not have to 
figure out/remember what version each device uses.

--
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.

Re: seandroid and policy version

[William Roberts]

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

Isn't that what ?= will let you do since it defers expansion? Again, I am
no make guru...

On Tue, Sep 18, 2012 at 12:04 PM, Joshua Brindle <jbrindle@tresys.com>wrote:

> Stephen Smalley wrote:
>
>> Attached are patches for libselinux and sepolicy to drop the policy
>> version suffix. We still force generation of a version 24 policy by
>> default, although this can be overridden via make command-line or
>> environment setting (e.g. export POLICYVERS=26). Does this seem sane?
>> Note that seandroid-4.0.4 requires changes to system/core as well, so
>> this only fixes it for master and 4.1.1.
>>
>>
> Looks fine to me. Any chance that POLICYVERS could be set in a device
> makefile? Since you'll know what kernel you are using to build a particular
> device it would be nice to set it there and not have to figure out/remember
> what version each device uses.
>



-- 
Respectfully,

William C Roberts

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

Re: seandroid and policy version

[Joshua Brindle]

Oh right, the precedence in this build system gets me sometimes...

William Roberts wrote:
> Isn't that what ?= will let you do since it defers expansion? Again, I
> am no make guru...
>
> On Tue, Sep 18, 2012 at 12:04 PM, Joshua Brindle <jbrindle@tresys.com
> <mailto:jbrindle@tresys.com>> wrote:
>
>     Stephen Smalley wrote:
>
>         Attached are patches for libselinux and sepolicy to drop the policy
>         version suffix. We still force generation of a version 24 policy by
>         default, although this can be overridden via make command-line or
>         environment setting (e.g. export POLICYVERS=26). Does this seem
>         sane?
>         Note that seandroid-4.0.4 requires changes to system/core as
>         well, so
>         this only fixes it for master and 4.1.1.
>
>
>     Looks fine to me. Any chance that POLICYVERS could be set in a
>     device makefile? Since you'll know what kernel you are using to
>     build a particular device it would be nice to set it there and not
>     have to figure out/remember what version each device uses.
>
>
>
>
> --
> Respectfully,
>
> William C Roberts
>
>

--
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.