On 4/12/2017 9:33 AM, Stephen Smalley wrote:
> On Wed, 2017-04-12 at 17:19 +0200, Sebastien Buisson wrote:
>> 2017-04-12 15:58 GMT+02:00 Stephen Smalley :
>>> Even your usage of selinux_is_enabled() looks suspect; that should
>>> probably go away. Only other user of it seems
On 4/12/2017 9:33 AM, Stephen Smalley wrote:
> On Wed, 2017-04-12 at 17:19 +0200, Sebastien Buisson wrote:
>> 2017-04-12 15:58 GMT+02:00 Stephen Smalley :
>>> Even your usage of selinux_is_enabled() looks suspect; that should
>>> probably go away. Only other user of it seems to be some cred
>>>
On Wed, 2017-04-12 at 19:07 +0200, Sebastien Buisson wrote:
> 2017-04-12 18:24 GMT+02:00 Stephen Smalley :
> > Maybe you want to register a notifier callback on policy reload?
> > See
> > the archives for the SELinux support for Infiniband RDMA patches
> > (which
> > seem to
On Wed, 2017-04-12 at 19:07 +0200, Sebastien Buisson wrote:
> 2017-04-12 18:24 GMT+02:00 Stephen Smalley :
> > Maybe you want to register a notifier callback on policy reload?
> > See
> > the archives for the SELinux support for Infiniband RDMA patches
> > (which
> > seem to have stalled), which
2017-04-12 18:24 GMT+02:00 Stephen Smalley :
> Maybe you want to register a notifier callback on policy reload? See
> the archives for the SELinux support for Infiniband RDMA patches (which
> seem to have stalled), which included LSM hooks and SELinux
> implementation to
2017-04-12 18:24 GMT+02:00 Stephen Smalley :
> Maybe you want to register a notifier callback on policy reload? See
> the archives for the SELinux support for Infiniband RDMA patches (which
> seem to have stalled), which included LSM hooks and SELinux
> implementation to support notifications on
On Wed, 2017-04-12 at 17:19 +0200, Sebastien Buisson wrote:
> 2017-04-12 15:58 GMT+02:00 Stephen Smalley :
> > Even your usage of selinux_is_enabled() looks suspect; that should
> > probably go away. Only other user of it seems to be some cred
> > validity
> > checking that
On Wed, 2017-04-12 at 17:19 +0200, Sebastien Buisson wrote:
> 2017-04-12 15:58 GMT+02:00 Stephen Smalley :
> > Even your usage of selinux_is_enabled() looks suspect; that should
> > probably go away. Only other user of it seems to be some cred
> > validity
> > checking that could be dropped as
On Wed, 2017-04-12 at 17:11 +0200, Sebastien Buisson wrote:
> 2017-04-12 16:35 GMT+02:00 Stephen Smalley :
> > How are you using this SELinux information in the kernel and/or in
> > userspace? What's the purpose of it? What are you comparing it
> > against? Why do you care
On Wed, 2017-04-12 at 17:11 +0200, Sebastien Buisson wrote:
> 2017-04-12 16:35 GMT+02:00 Stephen Smalley :
> > How are you using this SELinux information in the kernel and/or in
> > userspace? What's the purpose of it? What are you comparing it
> > against? Why do you care if it changes?
>
>
2017-04-12 15:58 GMT+02:00 Stephen Smalley :
> Even your usage of selinux_is_enabled() looks suspect; that should
> probably go away. Only other user of it seems to be some cred validity
> checking that could be dropped as well.
Well the main reason for calling
2017-04-12 15:58 GMT+02:00 Stephen Smalley :
> Even your usage of selinux_is_enabled() looks suspect; that should
> probably go away. Only other user of it seems to be some cred validity
> checking that could be dropped as well.
Well the main reason for calling selinux_is_enabled() is
2017-04-12 16:35 GMT+02:00 Stephen Smalley :
> How are you using this SELinux information in the kernel and/or in
> userspace? What's the purpose of it? What are you comparing it
> against? Why do you care if it changes?
Enforcement status and policy version are compared to
2017-04-12 16:35 GMT+02:00 Stephen Smalley :
> How are you using this SELinux information in the kernel and/or in
> userspace? What's the purpose of it? What are you comparing it
> against? Why do you care if it changes?
Enforcement status and policy version are compared to their previously
On Wed, 2017-04-12 at 15:30 +0200, Sebastien Buisson wrote:
> 2017-04-12 13:55 GMT+02:00 Paul Moore :
> > As currently written this code isn't something we would want to
> > merge
> > upstream for two important reasons:
> >
> > * No clear user of this functionality. There
On Wed, 2017-04-12 at 15:30 +0200, Sebastien Buisson wrote:
> 2017-04-12 13:55 GMT+02:00 Paul Moore :
> > As currently written this code isn't something we would want to
> > merge
> > upstream for two important reasons:
> >
> > * No clear user of this functionality. There needs to be a well
> >
On Wed, 2017-04-12 at 15:30 +0200, Sebastien Buisson wrote:
> 2017-04-12 13:55 GMT+02:00 Paul Moore :
> > As currently written this code isn't something we would want to
> > merge
> > upstream for two important reasons:
> >
> > * No abstraction layer at the LSM interface. The
On Wed, 2017-04-12 at 15:30 +0200, Sebastien Buisson wrote:
> 2017-04-12 13:55 GMT+02:00 Paul Moore :
> > As currently written this code isn't something we would want to
> > merge
> > upstream for two important reasons:
> >
> > * No abstraction layer at the LSM interface. The core kernel code
>
2017-04-12 13:55 GMT+02:00 Paul Moore :
> As currently written this code isn't something we would want to merge
> upstream for two important reasons:
>
> * No clear user of this functionality. There needs to be a well
> defined user of this functionality in the kernel.
The use
2017-04-12 13:55 GMT+02:00 Paul Moore :
> As currently written this code isn't something we would want to merge
> upstream for two important reasons:
>
> * No clear user of this functionality. There needs to be a well
> defined user of this functionality in the kernel.
The use case for this new
2017-04-12 13:55 GMT+02:00 Paul Moore :
> As currently written this code isn't something we would want to merge
> upstream for two important reasons:
>
> * No abstraction layer at the LSM interface. The core kernel code
> should not call directly into any specific LSM, all
2017-04-12 13:55 GMT+02:00 Paul Moore :
> As currently written this code isn't something we would want to merge
> upstream for two important reasons:
>
> * No abstraction layer at the LSM interface. The core kernel code
> should not call directly into any specific LSM, all interaction should
> go
On Wed, 2017-04-12 at 18:06 +0900, Sebastien Buisson wrote:
> Add selinux_is_enforced() function to give access to SELinux
> enforcement to the rest of the kernel.
>
> Signed-off-by: Sebastien Buisson
> ---
> include/linux/selinux.h | 5 +
>
On Wed, 2017-04-12 at 18:06 +0900, Sebastien Buisson wrote:
> Add selinux_is_enforced() function to give access to SELinux
> enforcement to the rest of the kernel.
>
> Signed-off-by: Sebastien Buisson
> ---
> include/linux/selinux.h | 5 +
> security/selinux/exports.c |
On Wed, Apr 12, 2017 at 5:06 AM, Sebastien Buisson
wrote:
> Add selinux_is_enforced() function to give access to SELinux
> enforcement to the rest of the kernel.
>
> Signed-off-by: Sebastien Buisson
> ---
> include/linux/selinux.h | 5 +
On Wed, Apr 12, 2017 at 5:06 AM, Sebastien Buisson
wrote:
> Add selinux_is_enforced() function to give access to SELinux
> enforcement to the rest of the kernel.
>
> Signed-off-by: Sebastien Buisson
> ---
> include/linux/selinux.h | 5 +
> security/selinux/exports.c | 6
Add selinux_is_enforced() function to give access to SELinux
enforcement to the rest of the kernel.
Signed-off-by: Sebastien Buisson
---
include/linux/selinux.h | 5 +
security/selinux/exports.c | 6 ++
security/selinux/hooks.c| 2 ++
Add selinux_is_enforced() function to give access to SELinux
enforcement to the rest of the kernel.
Signed-off-by: Sebastien Buisson
---
include/linux/selinux.h | 5 +
security/selinux/exports.c | 6 ++
security/selinux/hooks.c| 2 ++
28 matches
Mail list logo