On 05/21/2013 10:57 AM, Steve Beattie wrote:
On Tue, May 21, 2013 at 12:49:32AM -0700, John Johansen wrote:
On 05/21/2013 12:07 AM, Steve Beattie wrote:
- For all other namespaces
- the first profile is the init profile, and it is set as the default
profile
The first profile loaded? So
On Wed, May 22, 2013 at 12:32:47AM -0700, John Johansen wrote:
On 05/21/2013 10:57 AM, Steve Beattie wrote:
On Tue, May 21, 2013 at 12:49:32AM -0700, John Johansen wrote:
It comes back to my desire to grow namespaces as first class objects
in policy (I have no doubt they are first class in
On Sun, May 19, 2013 at 05:07:16AM -0700, John Johansen wrote:
Alright, here is a new proposal on it.
I'm generally on board. A couple of comments/questions inline:
When a profile is created the first profile it is created with is the init
profile.
- this profile is replaceable, and set as
On Tue, May 21, 2013 at 12:49:32AM -0700, John Johansen wrote:
On 05/21/2013 12:07 AM, Steve Beattie wrote:
- For all other namespaces
- the first profile is the init profile, and it is set as the default
profile
The first profile loaded? So profile load order matters here? Is there
On Sun, May 19, 2013 at 05:07:16AM -0700, John Johansen wrote:
When a profile is created the first profile it is created with is the
init profile.
- this profile is replaceable, and set as the default profile
- For the root namespace (namespace setup on boot)
- this profile is setup in the
On Mon, May 20, 2013 at 02:49:50PM -0700, John Johansen wrote:
On 05/20/2013 02:16 PM, Seth Arnold wrote:
On Sun, May 19, 2013 at 05:07:16AM -0700, John Johansen wrote:
- the default profile will be exposed to userspace via a file under
its namespace in aafs
- we could allow
On Wed, May 15, 2013 at 05:13:15PM -0700, John Johansen wrote:
So this is a new attempt to frame the default/init/system profile discussion
Thanks for writing this up (and opening the whole can of worms to begin
with, even if you end up regretting it :) ).
The goal of the default/system
On 05/16/2013 03:33 AM, John Johansen wrote:
snip
I think the problem with all the above is that you're still conflating
the initial_policy that is applied to init with the default_policy, an
Sigh, no sorry I guess I wasn't clear enough. I really tried to make that
split and provide
On Wed, May 15, 2013 at 05:13:15PM -0700, John Johansen wrote:
So this is a new attempt to frame the default/init/system profile discussion
Interesting. I like it.
There are several potential solutions to the problem of confining init
and its early children
1. Policy load in the
So this is a new attempt to frame the default/init/system profile discussion
The goal of the default/system profile is to replace the unconfined profile
and make it easier to have a default system policy and also to confine
applications from boot. The unconfined profile has few different
10 matches
Mail list logo
