On Thu, Oct 4, 2018 at 1:38 AM John Johansen
wrote:
> On 10/03/2018 10:26 AM, Kees Cook wrote:
...
> > Either a distro builds a very specific subset of LSMs, or they build
> > in all LSMs (for the user to choose from). In both cases, they set an
> > explicit order, which defines which exclusive
On Thu, Oct 4, 2018 at 9:58 PM, James Morris wrote:
> On Thu, 4 Oct 2018, Kees Cook wrote:
>
>> On Thu, Oct 4, 2018 at 10:49 AM, James Morris wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >> Then someone boots the system with:
>> >>
>> >> selinux=1 security=selinux
>> >>
>> >> In what order
On Fri, 5 Oct 2018, James Morris wrote:
> On Thu, 4 Oct 2018, Kees Cook wrote:
> > And a user would need to specify ALL lsms on the "lsm=" line?
> >
>
> Yes, the ones they want enabled.
If they're overriding the kconfig value.
--
James Morris
On Thu, 4 Oct 2018, Kees Cook wrote:
> On Thu, Oct 4, 2018 at 10:49 AM, James Morris wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >> Then someone boots the system with:
> >>
> >> selinux=1 security=selinux
> >>
> >> In what order does selinux get initialized relative to yama?
> >> (apparmor,
On Thu, Oct 4, 2018 at 10:49 AM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>> Then someone boots the system with:
>>
>> selinux=1 security=selinux
>>
>> In what order does selinux get initialized relative to yama?
>> (apparmor, flagged as a "legacy major", would have been disabled
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> > - All LSMs which are built are NOT enabled by default
> >
> > - You specify enablement and order via a Kconfig:
> >
> > CONFIG_LSM="selinux,yama"
On Wed, Oct 3, 2018 at 10:56 PM, John Johansen
wrote:
> On 10/03/2018 01:36 PM, Kees Cook wrote:
>> I still think we should have all built LSMs enabled by default, with
>> CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
>
> and this as a distro ubuntu does not want.
> Ubuntu wants
On Wed, Oct 3, 2018 at 10:38 PM, John Johansen
wrote:
> but distinct of first exclusive (major) will likely be going away
> once full lsm stacking land.
Right -- then policy loading because the "enabled" flag. The point is
to get us to where we don't care about exclusivity at all.
-Kees
--
Kee
On 10/03/2018 04:59 PM, Randy Dunlap wrote:
> On 10/3/18 4:55 PM, Kees Cook wrote:
>> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>>
On 10/03/2018 04:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wr
On 10/03/2018 01:36 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook wrote:
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> On Tue, 2 Oct 2018, John Johansen wrote
On 10/03/2018 10:26 AM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote:
>> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>>
>>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>>> wrote:
On 10/02/2018 04:06 PM, Kees Cook wrote:
>
> I think the current proposa
On Wed, Oct 3, 2018 at 4:59 PM, Randy Dunlap wrote:
> To me, "security=selinux" means SELinux and nothing else, so I think that
> all of these params are inviting a lot of confusion.
>
> Sorry, I don't have a good answer for this.
This part, at least, has a pretty clear solution. :) The consensus
On 10/3/18 4:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >
>> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>> >> > On Tue, 2 Oct 2018, John Johansen
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> >> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> >> To me a list like
> >> >> lsm.enable=X,Y,Z
On Wed, 3 Oct 2018, Kees Cook wrote:
> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
> in, since it's just a way to disable all the other majors.
Right, default doesn't make sense anymore.
--
James Morris
On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>>> > On Tue, 2 Oct 2018, John Johansen wrote:
>>> >> To me a list like
>>> >> lsm.enable=
On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> To me a list like
>> >> lsm.enable=X,Y,Z
>> >
>> > What about even simpler:
>> >
>> > lsm=sel
On 10/03/2018 01:26 PM, Kees Cook wrote:
On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote:
On 10/02/2018 07:54 PM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
wrote:
On 10/02/2018 04:06 PM, Kees Cook wrote:
I think the current proposal (in the other thread) is lik
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> To me a list like
> >> lsm.enable=X,Y,Z
> >
> > What about even simpler:
> >
> > lsm=selinux,!apparmor,yama
>
> We're going to have lsm.order=, so I'd l
On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> On Tue, 2 Oct 2018, John Johansen wrote:
>> To me a list like
>> lsm.enable=X,Y,Z
>
> What about even simpler:
>
> lsm=selinux,!apparmor,yama
We're going to have lsm.order=, so I'd like to keep it with a dot
separator (this makes it more li
On Tue, 2 Oct 2018, John Johansen wrote:
> To me a list like
> lsm.enable=X,Y,Z
What about even simpler:
lsm=selinux,!apparmor,yama
>
> is best as a single explicit enable list, and it would be best to avoid
> lsm.disable as it just introduces confusion.
>
> I do think per-LSM bootparams lo
On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote:
> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>> wrote:
>>>
>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
I think the current proposal (in the other thread) is likely the
sanest a
On 10/02/2018 07:54 PM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
wrote:
On 10/02/2018 04:06 PM, Kees Cook wrote:
I think the current proposal (in the other thread) is likely the
sanest approach:
- Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
- Drop CONFIG_SECURITY_APPARM
On 10/02/2018 05:12 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
> wrote:
>> On 10/02/2018 04:54 PM, Kees Cook wrote:
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_EN
On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
wrote:
> On 10/02/2018 04:54 PM, Kees Cook wrote:
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way
On 10/02/2018 04:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>> - Drop
On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
wrote:
> On 10/02/2018 04:06 PM, Kees Cook wrote:
>> I think the current proposal (in the other thread) is likely the
>> sanest approach:
>>
>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>> - All e
On 10/02/2018 04:06 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote:
>> On Tue, 2 Oct 2018, Kees Cook wrote:
>>
>>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>>> wrote:
Under the current scheme
lsm.enabled=selinux
could actually mean selinux
On 10/02/2018 03:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> wrote:
>>> Under the current scheme
>>>
>>> lsm.enabled=selinux
>>>
>>> could actually mean selinux,yama,loadpin,something_else are
>>> enabled. If we extend t
On Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> wrote:
>> > Under the current scheme
>> >
>> > lsm.enabled=selinux
>> >
>> > could actually mean selinux,yama,loadpin,something_else are
>> > enabled.
On Tue, 2 Oct 2018, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> wrote:
> > Under the current scheme
> >
> > lsm.enabled=selinux
> >
> > could actually mean selinux,yama,loadpin,something_else are
> > enabled. If we extend this behavior to when full stacking lands
> >
> > l
On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>>
>> Oh sure l
On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
wrote:
> On 10/02/2018 12:17 PM, Kees Cook wrote:
>> I could define CONFIG_LSM_ENABLE as being "additive" to
>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>
> Oh sure lets deal with my complaint about too many ways to c
On 10/02/2018 12:17 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> wrote:
>> Under the current scheme
>>
>> lsm.enabled=selinux
>>
>> could actually mean selinux,yama,loadpin,something_else are
>> enabled. If we extend this behavior to when full stacking lands
>>
>> lsm.en
On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
wrote:
> Under the current scheme
>
> lsm.enabled=selinux
>
> could actually mean selinux,yama,loadpin,something_else are
> enabled. If we extend this behavior to when full stacking lands
>
> lsm.enabled=selinux,yama
>
> might mean selinux,yama,apparm
On Tue, Oct 2, 2018 at 11:33 AM, Stephen Smalley wrote:
> On 10/02/2018 12:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
>> wrote:
>>>
>>> It's always documented as: "selinux=1 security=selinux" so security=
>>> should
>>> still do the job and selinux=1 become no-op,
On 10/02/2018 09:54 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
>
> The v3 patch set worked this way, yes. (The per-LSM enable defau
On 10/02/2018 12:54 PM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
wrote:
It's always documented as: "selinux=1 security=selinux" so security= should
still do the job and selinux=1 become no-op, no?
The v3 patch set worked this way, yes. (The per-LSM enable defaults
were s
On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
wrote:
> It's always documented as: "selinux=1 security=selinux" so security= should
> still do the job and selinux=1 become no-op, no?
The v3 patch set worked this way, yes. (The per-LSM enable defaults
were set by the LSM. Only in the case of "lsm.d
On Tue, Oct 2, 2018 at 7:58 AM, Stephen Smalley wrote:
> On 10/02/2018 10:44 AM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley wrote:
>>>
>>> On 10/02/2018 08:12 AM, Paul Moore wrote:
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
>
>
> Since
‐‐‐ Original Message ‐‐‐
On Tuesday, October 2, 2018 4:57 PM, Stephen Smalley wrote:
> On 10/02/2018 10:44 AM, Kees Cook wrote:
>
> > On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley s...@tycho.nsa.gov wrote:
> >
> > > On 10/02/2018 08:12 AM, Paul Moore wrote:
> > >
> > > > On Mon, Oct 1,
On 10/02/2018 10:44 AM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley wrote:
On 10/02/2018 08:12 AM, Paul Moore wrote:
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-
On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley wrote:
> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>
>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
>>>
>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
On 10/02/2018 08:12 AM, Paul Moore wrote:
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
SELinux.
Signed-off-by: Kees Cook
---
.../admin-guide/kernel-paramet
On Mon, Oct 1, 2018 at 9:04 PM Kees Cook wrote:
> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
> "lsm.enable=...", this removes the LSM-specific enabling logic from
> SELinux.
>
> Signed-off-by: Kees Cook
> ---
> .../admin-guide/kernel-parameters.txt | 9 --
> se
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
SELinux.
Signed-off-by: Kees Cook
---
.../admin-guide/kernel-parameters.txt | 9 --
security/selinux/Kconfig | 29 ---
48 matches
Mail list logo
