k sk_security, and if the case, reject the permissions.
>
> This adjustment is orthogonal to infrastructure improvements that may
> nullify the needed check, but should be added as good code hygiene.
>
> Signed-off-by: Mark Salyzyn
> Cc: Paul Moore
> Cc: Stephen Smalley
&
On Fri, 2018-01-19 at 12:19 -0500, Stephen Smalley wrote:
> On Thu, 2018-01-18 at 13:58 -0800, Mark Salyzyn wrote:
> > general protection fault: [#1] PREEMPT SMP KASAN
> > CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b
> > #28
> > task:
On Sat, 2017-10-21 at 15:43 +0200, Nicolas Belouin wrote:
> With CAP_SYS_ADMIN being bloated and inapropriate for actions such
> as mounting/unmounting filesystems, the creation of a new capability
> is needed.
> CAP_SYS_MOUNT is meant to give a process the ability to call for
> mount,
> umount and
On Fri, 2018-01-26 at 15:32 +0100, peter.enderb...@sony.com wrote:
> From: Peter Enderborg
>
> To be able to use rcu locks we seed to address the policydb
> though a pointer. This preparation removes the export of the
> policydb and send pointers to it through parameter agruments.
Just for refer
On Fri, 2018-01-26 at 15:32 +0100, peter.enderb...@sony.com wrote:
> Holding the preempt_disable is very bad for low latency tasks
> as audio and therefore we need to break out the rule-set dependent
> part from this disable. By using a RCU instead of rwlock we
> have an efficient locking and less
On Fri, 2018-01-26 at 15:32 +0100, peter.enderb...@sony.com wrote:
> From: Peter Enderborg
>
> This i preparation for switching to RCU locks. To be able to use
> RCU we need atomic switched pointer. This adds the dynamic
> memory copying to be a single pointer. It copy all the
> data structures i
On Wed, 2018-01-17 at 15:55 +0100, peter.enderb...@sony.com wrote:
> From: Peter Enderborg
>
> Holding the preempt_disable is very bad for low latency tasks
> as audio and therefore we need to break out the rule-set dependent
> part from this disable. By using a rwsem instead of rwlock we
> have
On 2/7/19 9:09 AM, Edwin Zimmerman wrote:
On Thursday, February 07, 2019 8:50 AM Al Viro wrote:
On Thu, Feb 07, 2019 at 03:44:54PM +0300, Denis Efremov wrote:
The path_chmod hook was changed in the commit
"switch security_path_chmod() to struct path *" (cdcf116d44e7).
The argument @mnt was remo
On 2/7/19 9:32 AM, Stephen Smalley wrote:
On 2/7/19 9:09 AM, Edwin Zimmerman wrote:
On Thursday, February 07, 2019 8:50 AM Al Viro wrote:
On Thu, Feb 07, 2019 at 03:44:54PM +0300, Denis Efremov wrote:
The path_chmod hook was changed in the commit
"switch security_path_chmod() to struct
On 12/13/18 9:58 AM, Vivek Goyal wrote:
On Wed, Dec 12, 2018 at 09:51:59AM -0500, Stephen Smalley wrote:
On 12/11/18 4:48 PM, Vivek Goyal wrote:
On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote:
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500
On 12/13/18 1:54 PM, Vivek Goyal wrote:
On Thu, Dec 13, 2018 at 11:12:31AM -0500, Stephen Smalley wrote:
[..]
Can you elaborate a bit more on how this is leaking data through overlay
mount. If it is, then why accessing file on lower is not equivalent of
leaking of data.
In the container use
On 11/28/18 12:03 PM, Vivek Goyal wrote:
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
On Tue, Nov 27, 2018 at 08:58:06PM +0100, Miklos Szeredi wrote:
[resending with fixed email address for Paul Moore]
Moving discussion
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
On 11/28/18 12:03 PM, Vivek Goyal wrote:
On Wed, Nov 28, 2018 at 11:00:09AM +0100, Miklos Szeredi wrote:
On Tue, Nov 27, 2018 at 10:05 PM Vivek Goyal wrote:
On Tue, Nov 27, 2018 at 08:58
On 11/29/18 11:16 AM, Stephen Smalley wrote:
On 11/29/18 6:04 AM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley
wrote:
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley
wrote:
[...]
Does the breaking commit (007ea44892e6
On 11/29/18 6:04 AM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 10:43 PM Stephen Smalley wrote:
On 11/28/18 3:24 PM, Miklos Szeredi wrote:
On Wed, Nov 28, 2018 at 8:32 PM Stephen Smalley wrote:
[...]
Does the breaking commit (007ea44892e6) fix a real bug affecting users?
If not
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
special files or execute regular files to whi
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that would still allow the mounter to read/write
sp
On 12/11/18 4:48 PM, Vivek Goyal wrote:
On Thu, Dec 06, 2018 at 03:26:26PM -0500, Stephen Smalley wrote:
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley
wrote:
Possibly I misunderstood you, but I don't
On 12/3/18 6:27 PM, Paul Moore wrote:
On Thu, Nov 29, 2018 at 5:22 PM Daniel Walsh wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley wrote:
Possibly I misunderstood you, but I don't think we want to copy-up on
permission denial, as that
On 12/4/18 10:15 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 09:30:53AM -0500, Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
On Thu, Nov 29, 2018 at 10:16 PM Stephen Smalley wrote:
On 11/29/18 4:03 PM, Stephen Smalley wrote:
On 11/29/18 2:47 PM, Miklos Szeredi wrote
On 12/4/18 9:45 AM, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley wrote:
On 12/4/18 8:32 AM, Miklos Szeredi wrote:
My proposed sequence would be
a) check task's creds against overlay inode, fail -> return fail, otherwise:
b) check mounter's creds agains
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still create little anomaly when mknod to client
is not allowed on context label. So a device file, which is on lowe
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100, Miklos Szeredi wrote:
On Tue, Dec 4, 2018 at 4:22 PM Vivek Goyal wrote:
Having said that, this still
On 12/5/18 8:43 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:49:16AM -0500, Stephen Smalley wrote:
On 12/4/18 11:17 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 11:05:46AM -0500, Stephen Smalley wrote:
On 12/4/18 10:42 AM, Vivek Goyal wrote:
On Tue, Dec 04, 2018 at 04:31:09PM +0100
On 3/4/19 12:01 PM, Mark Salyzyn wrote:
On 11/29/2018 05:49 AM, Vivek Goyal wrote:
So will override_creds=off solve the NFS issue also where all access will
happen with the creds of task now? Though it will stil require more
priviliges in task for other operations in overlay to succeed.
NFS pr
On 2/15/19 11:11 AM, David Howells wrote:
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split. This will also allow a
greater range of subjects to represented.
WHY DO THIS?
The problem is that SETA
On 2/15/19 11:07 AM, David Howells wrote:
Allow a single process to be forked directly into a container using a new
syscall, thereby 'booting' the container:
pid_t pid = fork_into_container(int container_fd);
This process will be the 'init' process of the container.
Further attempts to
On 05/10/2018 08:53 PM, Casey Schaufler wrote:
> From: Casey Schaufler
> Date: Thu, 10 May 2018 14:23:27 -0700
> Subject: [PATCH 10/23] LSM: Infrastructure management of the inode security
> blob
>
> Move management of the inode->i_security blob out
> of the individual security modules and into
On 05/10/2018 08:55 PM, Casey Schaufler wrote:
> From: Casey Schaufler
> Date: Thu, 10 May 2018 15:54:25 -0700
> Subject: [PATCH 20/23] LSM: Move common usercopy into
> security_getpeersec_stream
>
> The modules implementing hook for getpeersec_stream
> don't need to be duplicating the copy-to-u
On 05/14/2018 11:12 AM, Stephen Smalley wrote:
> On 05/10/2018 08:55 PM, Casey Schaufler wrote:
>> From: Casey Schaufler
>> Date: Thu, 10 May 2018 15:54:25 -0700
>> Subject: [PATCH 20/23] LSM: Move common usercopy into
>> security_getpeersec_stream
>>
>
On 09/26/2018 04:34 PM, Casey Schaufler wrote:
From: Casey Schaufler
A ptrace access check with mode PTRACE_MODE_SCHED gets called
from process switching code. This precludes the use of audit or avc,
as the locking is incompatible. The only available check that
can be made without using avc is
On 09/25/2018 08:38 AM, Jiri Kosina wrote:
From: Jiri Kosina
Currently, we are issuing IBPB only in cases when switching into a non-dumpable
process, the rationale being to protect such 'important and security sensitive'
processess (such as GPG) from data leak into a different userspace process
On 09/19/2018 12:52 PM, Taras Kondratiuk wrote:
When files on NFSv4 server are not properly labeled (label doesn't match
a policy on a client) they will end up with unlabeled_t type which is
too generic. We would like to be able to set a default context per
mount. 'defcontext' mount option looks
e62dc7b R12: 888099d993c0
> R13: 0008 R14: 888099d993c0 R15: 88808967f648
> FS: 7f70cd9e5700() GS:8880ae70()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0073c000 CR3: 96c4a000 CR4:
On 04/24/2018 11:22 AM, David Howells wrote:
> Stephen Smalley wrote:
>
>> Neither fsopen() nor fscontext_fs_write() appear to perform any kind of
>> up-front permission checking (DAC or MAC), although some security hooks may
>> be ultimately called to allocate structures
On 04/20/2018 11:35 AM, David Howells wrote:
> Paul Moore wrote:
>
>> Adding the SELinux mailing list to the CC line; in the future please
>> include the SELinux mailing list on patches like this. It would also
>> be very helpful to include "selinux" somewhere in the subject line
>> when the pat
On 04/23/2018 09:30 AM, David Herrmann wrote:
> Make sure to implement the new unix_stream_socketpair callback so the
> SO_PEERSEC call on socketpair(2)s will return correct information.
>
> Signed-off-by: David Herrmann
Acked-by: Stephen Smalley
> ---
> security/se
On 04/23/2018 08:54 AM, Igor Stoppa wrote:
> SELinux is one of the primary targets, when a system running it comes
> under attack.
>
> The reason is that, even if an attacker ishould manage to gain root,
> SELinux will still prevent most desirable actions.
>
> Even in a fully locked down system,
On 09/23/2018 01:09 PM, Casey Schaufler wrote:
On 9/23/2018 8:59 AM, Tetsuo Handa wrote:
On 2018/09/23 11:43, Kees Cook wrote:
I'm excited about getting this landed!
Soon. Real soon. I hope. I would very much like for
someone from the SELinux camp to chime in, especially on
the selinux_is_enab
On 09/25/2018 01:27 PM, Tong Zhang wrote:
Kernel Version: 4.18.5
Problem Description:
When setting nice value, it is checked by LSM function security_task_setnice().
see kernel/sched/core.c:3972 SYSCALL_DEFINE1(nice, int, increment)
We discovered a leaking path in android binder which allows u
On 09/25/2018 01:27 PM, Tong Zhang wrote:
Kernel Version: 4.18.5
Problem Description:
search_binary_handler() should be called after setting bprm using
prepare_binprm(),
and in prepare_binprm(), there’s a LSM hook security_bprm_set_creds(),
which can make a decision that binfmt cares.
We foun
On 09/25/2018 09:33 PM, Dave Chinner wrote:
On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote:
Hi,
I'm bringing up this issue again to let of LSM developers know the situation,
and would like to know your thoughts.
Several weeks ago I sent an email to the security list to discuss the i
On 08/29/2018 10:21 PM, Dmitry Vyukov wrote:
On Wed, Aug 29, 2018 at 7:17 PM, syzbot
wrote:
Hello,
syzbot found the following crash on:
HEAD commit:817e60a7a2bb Merge branch 'nfp-add-NFP5000-support'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1536d2
On 08/31/2018 12:16 PM, Stephen Smalley wrote:
On 08/31/2018 12:07 PM, Paul Moore wrote:
On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley
wrote:
On 08/29/2018 10:21 PM, Dmitry Vyukov wrote:
On Wed, Aug 29, 2018 at 7:17 PM, syzbot
wrote:
Hello,
syzbot found the following crash on:
HEAD
On 08/31/2018 12:07 PM, Paul Moore wrote:
On Fri, Aug 31, 2018 at 12:01 PM Stephen Smalley wrote:
On 08/29/2018 10:21 PM, Dmitry Vyukov wrote:
On Wed, Aug 29, 2018 at 7:17 PM, syzbot
wrote:
Hello,
syzbot found the following crash on:
HEAD commit:817e60a7a2bb Merge branch 'nf
On 07/27/2015 03:32 PM, Hugh Dickins wrote:
> On Fri, 24 Jul 2015, Stephen Smalley wrote:
>
>> The shm implementation internally uses shmem or hugetlbfs inodes
>> for shm segments. As these inodes are never directly exposed to
>> userspace and only accessed through the
On 08/06/2015 10:20 AM, Seth Forshee wrote:
> On Wed, Aug 05, 2015 at 04:19:03PM -0500, Eric W. Biederman wrote:
>> Seth Forshee writes:
>>
>>> On Wed, Jul 15, 2015 at 09:47:11PM -0500, Eric W. Biederman wrote:
Seth Forshee writes:
> Initially this will be used to eliminate the impl
On 08/06/2015 11:44 AM, Seth Forshee wrote:
> On Thu, Aug 06, 2015 at 10:51:16AM -0400, Stephen Smalley wrote:
>> On 08/06/2015 10:20 AM, Seth Forshee wrote:
>>> On Wed, Aug 05, 2015 at 04:19:03PM -0500, Eric W. Biederman wrote:
>>>> Seth Forshee writes:
>>&g
On 07/16/2015 09:23 AM, Stephen Smalley wrote:
> On 07/15/2015 03:46 PM, Seth Forshee wrote:
>> Unprivileged users should not be able to supply security labels
>> in filesystems, nor should they be able to supply security
>> contexts in unprivileged mounts. For any mount wher
On 07/22/2015 12:14 PM, Seth Forshee wrote:
> On Wed, Jul 22, 2015 at 12:02:13PM -0400, Stephen Smalley wrote:
>> On 07/16/2015 09:23 AM, Stephen Smalley wrote:
>>> On 07/15/2015 03:46 PM, Seth Forshee wrote:
>>>> Unprivileged users should not be able to supply secur
On 07/22/2015 04:25 PM, Stephen Smalley wrote:
> On 07/22/2015 12:14 PM, Seth Forshee wrote:
>> On Wed, Jul 22, 2015 at 12:02:13PM -0400, Stephen Smalley wrote:
>>> On 07/16/2015 09:23 AM, Stephen Smalley wrote:
>>>> On 07/15/2015 03:46 PM, Seth Forshee wrote:
>&
On 07/22/2015 08:46 AM, Morten Stevens wrote:
> 2015-06-17 13:45 GMT+02:00 Morten Stevens :
>> 2015-06-15 8:09 GMT+02:00 Daniel Wagner :
>>> On 06/14/2015 06:48 PM, Hugh Dickins wrote:
It appears that, at some point last year, XFS made directory handling
changes which bring it into lockde
On 07/22/2015 04:40 PM, Stephen Smalley wrote:
> On 07/22/2015 04:25 PM, Stephen Smalley wrote:
>> On 07/22/2015 12:14 PM, Seth Forshee wrote:
>>> On Wed, Jul 22, 2015 at 12:02:13PM -0400, Stephen Smalley wrote:
>>>> On 07/16/2015 09:23 AM, Stephen Smalley wrote:
>
On 07/23/2015 10:39 AM, Seth Forshee wrote:
> On Thu, Jul 23, 2015 at 09:57:20AM -0400, Stephen Smalley wrote:
>> On 07/22/2015 04:40 PM, Stephen Smalley wrote:
>>> On 07/22/2015 04:25 PM, Stephen Smalley wrote:
>>>> On 07/22/2015 12:14 PM, Seth Forshee wrote:
>&
ose+0x34/0x130
[] remove_vma+0x45/0x80
[] do_munmap+0x2b0/0x460
[] ? SyS_shmdt+0x4b/0x180
[] SyS_shmdt+0xb5/0x180
[] entry_SYSCALL_64_fastpath+0x12/0x76
Reported-by: Morten Stevens
Signed-off-by: Stephen Smalley
---
fs/hugetlbfs/inode.c | 2 ++
ipc/shm.c| 2 +-
mm/shmem.c | 4 ++--
3
[] ? SyS_shmdt+0x4b/0x180
Jul 22 14:36:40 fc23 kernel: [] SyS_shmdt+0xb5/0x180
Jul 22 14:36:40 fc23 kernel: []
entry_SYSCALL_64_fastpath+0x12/0x76
Reported-by: Morten Stevens
Signed-off-by: Stephen Smalley
---
This version only differs in the patch description, which restores
the original lockde
On 07/23/2015 08:11 PM, Dave Chinner wrote:
> On Thu, Jul 23, 2015 at 12:28:33PM -0400, Stephen Smalley wrote:
>> The shm implementation internally uses shmem or hugetlbfs inodes
>> for shm segments. As these inodes are never directly exposed to
>> userspace and only acc
On 07/24/2015 11:11 AM, Seth Forshee wrote:
> On Thu, Jul 23, 2015 at 11:23:31AM -0500, Seth Forshee wrote:
>> On Thu, Jul 23, 2015 at 11:36:03AM -0400, Stephen Smalley wrote:
>>> On 07/23/2015 10:39 AM, Seth Forshee wrote:
>>>> On Thu, Jul 23, 2015 at 09:57:20A
On 07/15/2015 09:05 PM, Andy Lutomirski wrote:
> On Jul 15, 2015 3:34 PM, "Eric W. Biederman" wrote:
>>
>> Seth Forshee writes:
>>
>>> On Wed, Jul 15, 2015 at 04:06:35PM -0500, Eric W. Biederman wrote:
Casey Schaufler writes:
> On 7/15/2015 12:46 PM, Seth Forshee wrote:
>> Thes
On 07/15/2015 03:46 PM, Seth Forshee wrote:
> Unprivileged users should not be able to supply security labels
> in filesystems, nor should they be able to supply security
> contexts in unprivileged mounts. For any mount where s_user_ns is
> not init_user_ns, force the use of SECURITY_FS_USE_NONE be
On Thu, 2017-05-11 at 21:59 +0900, Sebastien Buisson wrote:
> Add policybrief field to struct policydb. It holds a brief info
> of the policydb, in the following form:
> <0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
> Policy brief is computed every time the policy is loaded, and when
> enforce o
On Thu, 2017-05-11 at 08:56 -0700, Casey Schaufler wrote:
> On 5/11/2017 5:59 AM, Sebastien Buisson wrote:
> > Add policybrief field to struct policydb. It holds a brief info
> > of the policydb, in the following form:
> > <0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
> > Policy brief is compute
On Wed, 2017-04-26 at 08:38 -0700, Casey Schaufler wrote:
> On 4/26/2017 8:02 AM, Sebastien Buisson wrote:
> > From: Daniel Jurgens
> >
> > Add a generic notification mechanism in the LSM. Interested
> > consumers
> > can register a callback with the LSM and security modules can
> > produce
> > e
On Thu, 2017-04-27 at 00:02 +0900, Sebastien Buisson wrote:
> Add policycksum field to struct policydb. It holds the sha256
> checksum computed on the binary policy every time the notifier is
> called after a policy change.
> Add security_policy_cksum hook to give access to policy checksum to
> the
On Thu, 2017-04-27 at 00:02 +0900, Sebastien Buisson wrote:
> Expose policy SHA256 checksum via selinuxfs.
>
> Signed-off-by: Sebastien Buisson
> ---
> security/selinux/selinuxfs.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/security/selinux/selinuxfs.c
> b/se
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 security_set_boo
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
> > no
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, 2017-04-12 at 18:12 +0900, Sebastien Buisson wrote:
> Add selinux_status_get_seq() function to give access to sequence
> number of current SELinux policy loaded to the rest of the kernel.
>
> Signed-off-by: Sebastien Buisson
> ---
> include/linux/selinux.h | 7 +++
> security/s
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
> >
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
> > d
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
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
> > checki
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
>
On Fri, 2017-05-05 at 19:10 +0900, Sebastien Buisson wrote:
> Add policybrief field to struct policydb. It holds a brief info
> of the policydb, in the following form:
> <0 or 1 for enforce>:<0 or 1 for checkreqprot>:=
> Policy brief is computed every time the policy is loaded, and when
> enforce o
On Fri, 2017-04-28 at 17:16 +0200, Sebastien Buisson wrote:
> 2017-04-27 20:47 GMT+02:00 Stephen Smalley :
> > > I just checked, with the method of computing the checksum on a
> > > (data,
> > > len) pair on entry to security_load_policy() the checksum does
>
On Fri, 2017-04-28 at 18:08 +0200, Sebastien Buisson wrote:
> 2017-04-28 17:50 GMT+02:00 Stephen Smalley :
> > You seem to be conflating kernel policy with userspace policy.
> > security_load_policy() is provided with the kernel policy image,
> > which
> > is the r
On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote:
> On 29 March 2017 at 23:34, J. Bruce Fields
> wrote:
> > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote:
> > > Labelling of files in a NFSv4.2 currently fails with ENOTSUPP
> > > because
> > > the mount point doesn't have SBLABE
On Thu, 2017-03-30 at 13:41 -0400, J. Bruce Fields wrote:
> On Thu, Mar 30, 2017 at 01:27:07PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote:
> > > On 29 March 2017 at 23:34, J. Bruce Fields
> > > wrote:
> > > > O
xattr to be discarded on the copy, -EOPNOTSUPP
> if the security module does not handle/manage the xattr, or a -errno
> upon an error.
>
> Signed-off-by: David Howells
> Signed-off-by: Vivek Goyal
Acked-by: Stephen Smalley
> ---
> fs/overlayfs/copy_up.c| 7 +++
nes
> the label/context dentry will get if it had been created by task in upper
> and modify passed set of creds appropriately. Caller makes use of these new
> creds for file creation.
>
> Signed-off-by: Vivek Goyal
Acked-by: Stephen Smalley
> ---
> fs/overlayfs/dir.c
which are suitable for new file
> creation during copy up. Caller will use new creds to create file and then
> revert back to old creds and release new creds.
>
> Signed-off-by: Vivek Goyal
Acked-by: Stephen Smalley
> ---
> fs/overlayfs/copy_up.c| 15
On 07/08/2016 12:19 PM, Vivek Goyal wrote:
> Provide a security hook to label new file correctly when a file is copied
> up from lower layer to upper layer of a overlay/union mount.
>
> This hook can prepare a new set of creds which are suitable for new file
> creation during copy up. Caller will
On 07/08/2016 12:19 PM, Vivek Goyal wrote:
> Provide a security hook which is called when xattrs of a file are being
> copied up. This hook is called once for each xattr and LSM can return 0
> to access the xattr, 1 to reject xattr, -EOPNOTSUPP if none of the lsms
> claim to know xattr and a negati
also allow containers to write only to the systemd
> cgroup
> for instance, while the other cgroups are kept with cgroup_t label.
>
> Signed-off-by: Antonio Murdaca
Acked-by: Stephen Smalley
> ---
> Changes in v2:
> - whitelist cgroup2 fs type
>
> secur
On Mon, 2017-02-27 at 19:18 -0500, Paul Moore wrote:
> On Mon, Feb 27, 2017 at 4:23 PM, Stephen Smalley
> wrote:
> >
> > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> > >
> > > On Mon, Feb 27, 2017 at 11:53 AM, S
even when
no privilege was exercised, and is inefficient. Flip the order
of the tests in both functions so that we only call capable() if
the capability is truly required for the operation.
Signed-off-by: Stephen Smalley
---
fs/timerfd.c | 8
1 file changed, 4 insertions(+), 4 deletions
checked when required for
the operation.
Signed-off-by: Stephen Smalley
---
fs/namei.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index ad74877..8736e4a 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -340,22 +340,14 @@ int
On Thu, 2017-02-23 at 19:01 -0500, Paul Moore wrote:
> On Thu, Feb 23, 2017 at 1:43 PM, John Stultz
> wrote:
> >
> > Hey folks,
> > I've not been able to figure out why yet, but I wanted to raise
> > the
> > issue that last night I found I couldn't boot Android on my Hikey
> > board with Linus
On Mon, 2017-02-27 at 16:23 -0500, Stephen Smalley wrote:
> On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> >
> > On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley > v>
> > wrote:
> > >
> > >
> > > >
> > > >
On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> On Mon, Feb 27, 2017 at 11:53 AM, Stephen Smalley
> wrote:
> >
> > >
> > > I can reproduce it on angler (with a back-port of just that
> > > patch),
> > > although I am unclear on
On Mon, 2017-02-27 at 14:42 -0500, Stephen Smalley wrote:
> On Thu, 2017-02-23 at 19:01 -0500, Paul Moore wrote:
> >
> > On Thu, Feb 23, 2017 at 1:43 PM, John Stultz > g>
> > wrote:
> > >
> > >
> > > Hey folks,
> > > I'
On Thu, 2017-03-09 at 18:28 +0100, Greg KH wrote:
> On Mon, Feb 27, 2017 at 04:23:28PM -0500, Stephen Smalley wrote:
> >
> > On Mon, 2017-02-27 at 12:48 -0800, Nick Kralevich wrote:
> > >
> > > On Mon, Feb 27, 2017 at 11:53 AM, Step
checked when required for
the operation.
Signed-off-by: Stephen Smalley
---
fs/namei.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index d41fab7..482414a 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -340,22 +340,14 @@ int
On Fri, 2017-03-10 at 15:01 -0500, Paul Moore wrote:
> On Thu, Feb 9, 2017 at 10:58 AM, Antonio Murdaca > wrote:
> >
> > This patch allows genfscon per-file labeling for cgroupfs. For
> > instance,
> > this allows to label the "release_agent" file within each
> > cgroup mount and limit writes to
On 06/21/2016 05:41 AM, Michael Kerrisk (man-pages) wrote:
> Hi Jann, Stephen, et al.
>
> Jann, since you recently committed a patch in this area, and Stephen,
> since you committed 006ebb40d3d much further back in time, I wonder if
> you might help me by reviewing the text below that I propose to
On 07/13/2016 10:44 AM, Vivek Goyal wrote:
> Provide a security hook to label new file correctly when a file is copied
> up from lower layer to upper layer of a overlay/union mount.
>
> This hook can prepare a new set of creds which are suitable for new file
> creation during copy up. Caller will
unt
> cases. In case of non-context mount, overlay inode will have the label
> of lower file and in case of context mount, overlay inode will have
> the label from context= mount option.
>
> Signed-off-by: Vivek Goyal
Acked-by: Stephen Smalley
> ---
> security/selinux/hoo
copy up label as newly created file got its label from context= option.
>
> Signed-off-by: Vivek Goyal
Acked-by: Stephen Smalley
> ---
> security/selinux/hooks.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/se
301 - 400 of 584 matches
Mail list logo
