Re: [PATCH] selinux: only invoke capabilities and selinux for CAP_MAC_ADMIN checks

2017-04-27 Thread Paul Moore
On Thu, Apr 27, 2017 at 9:19 AM, Stephen Smalley wrote: > On Wed, 2017-04-26 at 17:36 -0400, Paul Moore wrote: >> On Thu, Apr 20, 2017 at 11:31 AM, Stephen Smalley >> wrote: >> > SELinux uses CAP_MAC_ADMIN to control the ability to get or set a >> > raw,

Re: is_selinux_enabled() always returns 0 after selinux_set_policy_root()

2017-04-27 Thread Stephen Smalley
On Thu, 2017-04-27 at 18:53 +0200, Dominick Grift wrote: > On Thu, Apr 27, 2017 at 09:04:11AM -0400, Stephen Smalley wrote: > > On Wed, 2017-04-26 at 17:08 -0400, Colin Walters wrote: > > > > > > On Wed, Apr 26, 2017, at 04:43 PM, Colin Walters wrote: > > > > On Wed, Apr 26, 2017, at 04:24 PM,

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 Thread Stephen Smalley
On Thu, 2017-04-27 at 19:12 +0200, Sebastien Buisson wrote: > 2017-04-27 17:18 GMT+02:00 Stephen Smalley : > > Ok, that should work as long as you just want to validate that all > > the > > clients loaded the same policy file, and aren't concerned about > > non- > > persistent

Re: is_selinux_enabled() always returns 0 after selinux_set_policy_root()

2017-04-27 Thread Dominick Grift
On Thu, Apr 27, 2017 at 09:04:11AM -0400, Stephen Smalley wrote: > On Wed, 2017-04-26 at 17:08 -0400, Colin Walters wrote: > > > > On Wed, Apr 26, 2017, at 04:43 PM, Colin Walters wrote: > > > On Wed, Apr 26, 2017, at 04:24 PM, Stephen Smalley wrote: > > > > > > > > Your analysis and proposed

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 Thread Stephen Smalley
On Thu, 2017-04-27 at 10:41 +0200, Sebastien Buisson wrote: > 2017-04-26 20:30 GMT+02:00 Stephen Smalley : > > This seems like an odd place to trigger the computation. > > I noticed that the policy as exposed via /sys/fs/selinux/policy can > also be modified in

Re: [PATCH] libselinux: Add permissive= entry to avc audit log

2017-04-27 Thread Stephen Smalley
On Wed, 2017-04-26 at 14:47 +0100, Richard Haines wrote: > Add audit log entry to specify whether the decision was made in > permissive mode/permissive domain or enforcing mode. > > There are two utilities for testing: > utils/avc_has_perm - This can set the AVC mode to follow SELinux, set > AVC

Re: [PATCH] selinux: only invoke capabilities and selinux for CAP_MAC_ADMIN checks

2017-04-27 Thread Stephen Smalley
On Wed, 2017-04-26 at 17:36 -0400, Paul Moore wrote: > On Thu, Apr 20, 2017 at 11:31 AM, Stephen Smalley > wrote: > > SELinux uses CAP_MAC_ADMIN to control the ability to get or set a > > raw, > > uninterpreted security context unknown to the currently loaded > > security > >

Re: is_selinux_enabled() always returns 0 after selinux_set_policy_root()

2017-04-27 Thread Stephen Smalley
On Wed, 2017-04-26 at 17:08 -0400, Colin Walters wrote: > > On Wed, Apr 26, 2017, at 04:43 PM, Colin Walters wrote: > > On Wed, Apr 26, 2017, at 04:24 PM, Stephen Smalley wrote: > > > > > > Your analysis and proposed fix sound correct to me.  I blame Dan > > > ;) > > > > Thanks.  I tested the

Re: is_selinux_enabled() always returns 0 after selinux_set_policy_root()

2017-04-27 Thread Stephen Smalley
On Wed, 2017-04-26 at 16:43 -0400, Colin Walters wrote: > On Wed, Apr 26, 2017, at 04:24 PM, Stephen Smalley wrote: > > > > Your analysis and proposed fix sound correct to me.  I blame Dan ;) > > Thanks.  I tested the patch and confirmed it fixed ostree as it > stands today, > but I'm going to

Re: [PATCH 2/3] selinux: add checksum to policydb

2017-04-27 Thread Sebastien Buisson
2017-04-26 20:30 GMT+02:00 Stephen Smalley : > This seems like an odd place to trigger the computation. I noticed that the policy as exposed via /sys/fs/selinux/policy can also be modified in security_set_bools(). So in order to limit the places from where to compute the

Re: [PATCH] selinux: fix double free in selinux_parse_opts_str()

2017-04-27 Thread Tetsuo Handa
Paul Moore wrote: > On Fri, Mar 24, 2017 at 10:55 PM, Tetsuo Handa > wrote: > > Paul Moore wrote: > >> Hi, > >> > >> Thank you very much for this patch, but I think we need to look a bit > >> harder at this problem as it appears that many callers assume that >