On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman wrote:
[...]
>
> The only option I have seen proposed that might qualify as something
> general purpose and simple is a new filesystem that is just the process
> directories of proc. As there would in essence be no files that would
> need restrict
On Mon, Dec 4, 2017 at 2:58 PM, Jessica Yu wrote:
> +++ Djalal Harouni [04/12/17 10:01 +0100]:
>>
>> On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez
>> wrote:
>>>
>>> On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote:
>>>>
>>
On Thu, Nov 30, 2017 at 7:39 PM, Luis R. Rodriguez wrote:
> On Thu, Nov 30, 2017 at 02:17:11PM +0100, Jessica Yu wrote:
>> Just some quick questions - are there any plans to use these in-kernel
>> module aliases anywhere else? Or are you using them just for debugging?
>
> As-is for now just debugg
On Thu, Nov 30, 2017 at 3:16 PM, Theodore Ts'o wrote:
> On Thu, Nov 30, 2017 at 09:50:27AM +0100, Djalal Harouni wrote:
>> In embedded systems we can't maintain a SELinux policy, distro man
>> power hardly manage. We have abstracted seccomp etc, but the kernel
>> in
On Thu, Nov 30, 2017 at 2:23 AM, Luis R. Rodriguez wrote:
> On Mon, Nov 27, 2017 at 06:18:36PM +0100, Djalal Harouni wrote:
>> diff --git a/include/linux/module.h b/include/linux/module.h
>> index 5cbb239..c36aed8 100644
>> --- a/include/linux/module.h
>> +++ b/include/
On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay wrote:
[...]
> Lots of potential module attack surface also gets eliminated by default
> via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl
> commands, etc. The global seccomp whitelist might be relevant in some
> cases too.
In embedde
On Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote:
> On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote:
>> As I've said before, this isn't a theoretical attack surface. This
>> year alone there have been three known-exploitable flaws exposed by
>> autoloading:
>>
>> The exploit for CVE
On Tue, Nov 28, 2017 at 11:18 PM, Luis R. Rodriguez wrote:
> On Tue, Nov 28, 2017 at 10:33:27PM +0100, Djalal Harouni wrote:
>> On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez
>> wrote:
>> > On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote:
>> >&
On Tue, Nov 28, 2017 at 10:16 PM, Luis R. Rodriguez wrote:
> On Tue, Nov 28, 2017 at 12:11:34PM -0800, Kees Cook wrote:
>> On Tue, Nov 28, 2017 at 11:14 AM, Luis R. Rodriguez
>> wrote:
>> > kmod is just a helper to poke userpsace to load a module, that's it.
>> >
>> > The old init_module() and n
On Tue, Nov 28, 2017 at 9:33 PM, Linus Torvalds
wrote:
> On Tue, Nov 28, 2017 at 12:20 PM, Kees Cook wrote:
>>
>> So what's the right path forward for allowing a way to block
>> autoloading? Separate existing request_module() calls into "must be
>> privileged" and "can be unpriv" first, then rewo
Hi Luis,
On Tue, Nov 28, 2017 at 8:14 PM, Luis R. Rodriguez wrote:
> On Mon, Nov 27, 2017 at 06:18:34PM +0100, Djalal Harouni wrote:
> ...
>
>> After a discussion with Rusty Russell [1], the suggestion was to pass
>> the capability from request_module() to security_kernel_mo
Hi Linus,
On Mon, Nov 27, 2017 at 7:44 PM, Linus Torvalds
wrote:
> On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote:
>> This uses the new request_module_cap() facility to directly propagate
>> CAP_NET_ADMIN capability and the 'netdev' module prefix to the
>>
Hi Randy,
On Mon, Nov 27, 2017 at 7:48 PM, Randy Dunlap wrote:
> Hi,
>
> Mostly typos/spellos...
>
>
> On 11/27/2017 09:18 AM, Djalal Harouni wrote:
>> Cc: Serge Hallyn
>> Cc: Andy Lutomirski
>> Suggested-by: Rusty Russell
>> Suggested-by: K
Hi Linus,
On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds
wrote:
> On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds
> wrote:
>>
>> Now, the above will not necessarily work with a legacy /dev/ directory
>> where al the nodes have been pre-populated, and opening the device
>> node is supposed to l
ading is
disabled forever.
[1] http://www.openwall.com/lists/oss-security/2017/02/22/3
[2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074
[3] http://www.openwall.com/lists/oss-security/2017/03/29/2
[4] http://www.openwall.com/lists/oss-security/2017/03/07/6
[5] https://a13xp0p0v.
w.openwall.com/lists/oss-security/2017/02/22/3
[2] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074
[3] http://www.openwall.com/lists/oss-security/2017/03/29/2
[4] http://www.openwall.com/lists/oss-security/2017/03/07/6
[5] https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html
ed on patch by Rusty Russell and discussion with Kees Cook:
[1] https://lkml.org/lkml/2017/4/26/735
[2] https://lkml.org/lkml/2017/5/23/775
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
include/linux/kmod.h |
ns from Rusty Russel and Kees Cook [1]
[1] https://lkml.org/lkml/2017/4/26/735
Cc: Ben Hutchings
Cc: James Morris
Cc: Serge Hallyn
Cc: Solar Designer
Cc: Andy Lutomirski
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
net/core/dev_ioctl.c | 4 +++
patch.
Cc: James Morris
Cc: Serge Hallyn
Cc: Andy Lutomirski
Cc: Ben Hutchings
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
include/linux/module.h | 10 ++
include/linux/security.h | 4 +++-
kernel/module.c | 23
by: Kees Cook
*) Improved documentation.
*) Removed unused code.
# Changes since v1:
*) Renamed module to ModAutoRestrict
*) Improved documentation to explicity refer to module autoloading.
*) Switched to use the new task_security_alloc() hook.
*) Switched from rhash tables to use task->security since
On Fri, Nov 10, 2017 at 11:31 AM, Alexey Dobriyan wrote:
> On 11/9/17, Djalal Harouni wrote:
>
>> struct proc_fs_info {
>> struct pid_namespace *pid_ns;
>> + struct dentry *proc_self; /* For /proc/self/ */
>> + struct dentry *proc_thread_
On Fri, Nov 10, 2017 at 11:36 AM, Alexey Dobriyan wrote:
> On 11/9/17, Djalal Harouni wrote:
>> --- a/fs/proc/base.c
>> +++ b/fs/proc/base.c
>
>> -static bool has_pid_permissions(struct pid_namespace *pid,
>> +static bool has_pid_permissions(struct proc_fs_
On Fri, Nov 10, 2017 at 3:38 AM, Andy Lutomirski wrote:
> On Thu, Nov 9, 2017 at 8:14 AM, Djalal Harouni wrote:
>> This patch introduces the new 'pids' mount option, as it was discussed
>> and suggested by Andy Lutomirski [1].
>>
>> * If 'pids='
On Fri, Nov 10, 2017 at 3:53 AM, James Morris wrote:
> On Thu, 9 Nov 2017, Djalal Harouni wrote:
>
>> This should allow later after real testing to have a smooth transition
>> to a procfs with default private instances.
>>
>> [1]
>> https://lists.linuxfoun
On Fri, Nov 10, 2017 at 11:26 AM, Alexey Dobriyan wrote:
> On 11/9/17, Djalal Harouni wrote:
>
>> +struct proc_fs_info {
>> + struct pid_namespace *pid_ns;
>> +};
>
>> +static inline struct proc_fs_info *proc_sb(struct super_block *sb)
>> +{
>>
it-discuss/2017-January/004215.html
[2] http://www.openwall.com/lists/kernel-hardening/2017/10/05/5
[3]
http://lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.14
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Suggested-by: Andy Lutomirski
Signed-off-by: Alexey Gladkov
Signed-off-
, and we want to make sure that unmounting a private procfs
won't clash with other procfs mounts.
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Suggested-by: Andy Lutomirski
Signed-off-by: Alexey Gladkov
Signed-off-by: Djalal Harouni
---
fs/proc/base.c| 4 ++--
fs/proc/r
truct. First
lets fix the access.
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Suggested-by: Andy Lutomirski
Signed-off-by: Alexey Gladkov
Signed-off-by: Djalal Harouni
---
fs/proc/base.c | 16 +---
fs/proc/inode.c | 5 +++--
fs/proc/internal.h | 2 +-
fs/proc/r
lets
move this last bit to where it really belongs.
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Cc: Andy Lutomirski
Signed-off-by: Alexey Gladkov
Signed-off-by: Djalal Harouni
---
include/linux/pid_namespace.h | 6 --
include/linux/proc_fs.h | 6 ++
2 files changed, 6 insertions(+),
[1] https://lkml.org/lkml/2017/4/26/646
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Suggested-by: Andy Lutomirski
Signed-off-by: Alexey Gladkov
Signed-off-by: Djalal Harouni
---
fs/proc/base.c | 36 +---
fs/proc/inode.c | 6 +-
fs/proc/root.c
lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.14
[5] https://lkml.org/lkml/2017/5/2/407
[6] https://lkml.org/lkml/2017/5/3/357
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Suggested-by: Andy Lutomirski
Signed-off-by: Alexey Gladkov
Signed-off-by: Djalal Harouni
---
fs/proc/
Flush dcache entries of a task when it terminates. The task may have
showed up in multiple procfs mounts per pid namespace, and we need to
walk the mounts and invalidate any left entires.
Cc: Kees Cook
Cc: Greg Kroah-Hartman
Cc: Andy Lutomirski
Cc: Alexey Gladkov
Signed-off-by: Djalal Harouni
enamed mount options to 'newinstance' and 'pids='
Suggested-by: Andy Lutomirski
*) Fixed order of commit, Suggested-by: Andy Lutomirski
*) Many bug fixes.
# Changes since RFC v1:
*) Removed 'unshared' mount option and replaced it with 'limit_pids'
wh
Hi Alexey,
On Sun, Sep 24, 2017 at 9:08 PM, Alexey Dobriyan wrote:
> From: Tatsiana Brouka
>
> Implement system call for bulk retrieveing of pids in binary form.
>
> Using /proc is slower than necessary: 3 syscalls + another 3 for each thread +
> converting with atoi() + instantiating dentries a
Hi Alexey,
On Thu, Sep 7, 2017 at 4:04 AM, Andy Lutomirski wrote:
> On Wed, Sep 6, 2017 at 2:04 AM, Alexey Dobriyan wrote:
>> On 9/6/17, Randy Dunlap wrote:
>>> On 09/05/17 15:53, Andrew Morton wrote:
[...]
>>>
>>> also, I expect that the tiny kernel people will want kconfig options for
>>> the
Hi Kees,
On Thu, Jun 1, 2017 at 9:10 PM, Kees Cook wrote:
> On Thu, Jun 1, 2017 at 7:56 AM, Djalal Harouni wrote:
...
>
>> BTW Kees, also in next version I won't remove the
>> capable(CAP_NET_ADMIN) check from [1]
>> even if there is the new request_module_cap(),
On Tue, May 30, 2017 at 7:59 PM, Kees Cook wrote:
[...]
>>> I see a few options:
>>>
>>> 1) keep what you have for v4, and hope other places don't use
>>> __request_module. (I'm not a fan of this.)
>>
>> Yes even if it is documented I wouldn't bet on it, though. :-)
>
> Okay, we seem to agree: we'
On Tue, May 23, 2017 at 9:48 AM, Solar Designer wrote:
>> >>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer
>> >>> wrote:
>> >>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>> >>> >> *) When module
On Tue, May 23, 2017 at 9:19 PM, Kees Cook wrote:
> On Tue, May 23, 2017 at 3:29 AM, Djalal Harouni wrote:
[...]
>> I think if there is an interface request_module_capable() , then code
>> will use it. The DCCP code path did not check capabilities at all and
>> called re
On Tue, May 23, 2017 at 2:54 PM, Eric W. Biederman
wrote:
> Jeff Layton writes:
>
>> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
>>> David Howells writes:
>>>
>>> > Here are a set of patches to define a container object for the kernel and
>>> > to provide some methods to create a
On Tue, May 23, 2017 at 12:22 AM, Jeff Layton wrote:
> On Mon, 2017-05-22 at 14:04 -0500, Eric W. Biederman wrote:
>> David Howells writes:
>>
>> > Here are a set of patches to define a container object for the kernel and
>> > to provide some methods to create and manipulate them.
>> >
>> > The r
On Tue, May 23, 2017 at 1:38 AM, Andy Lutomirski wrote:
> On Mon, May 22, 2017 at 4:07 PM, Kees Cook wrote:
>> On Mon, May 22, 2017 at 12:55 PM, Djalal Harouni wrote:
>>> On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote:
>>>> On Mon, May 22, 2017 at 03:49:15
On Tue, May 23, 2017 at 12:20 AM, Kees Cook wrote:
> On Mon, May 22, 2017 at 4:57 AM, Djalal Harouni wrote:
>> This is a preparation patch for the module auto-load restriction feature.
>>
>> In order to restrict module auto-load operations we need to check if the
>>
On Mon, May 22, 2017 at 6:43 PM, Solar Designer wrote:
> On Mon, May 22, 2017 at 03:49:15PM +0200, Djalal Harouni wrote:
>> On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote:
>> > On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>> >> *) When modu
Hi Alexander,
On Mon, May 22, 2017 at 2:08 PM, Solar Designer wrote:
> Hi Djalal,
>
> Thank you for your work on this!
>
> On Mon, May 22, 2017 at 01:57:03PM +0200, Djalal Harouni wrote:
>> *) When modules_autoload_mode is set to (2), automatic module loading is
>>
[1] http://www.openwall.com/lists/oss-security/2017/02/22/3
[2] http://www.openwall.com/lists/oss-security/2017/03/29/2
[3] https://github.com/xairy/kernel-exploits/tree/master/CVE-2017-6074
Cc: Ben Hutchings
Cc: Rusty Russell
Cc: James Morris
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-
sandboxed apps or containers will be
restricted to trigger automatic module loading, other parts of the
system can continue to use the system as it is which is the case of the
desktop.
[1] http://www.openwall.com/lists/oss-security/2017/02/22/3
[2] http://www.openwall.com/lists/oss-security
equest() hook.
Based on patch by Rusty Russell:
https://lkml.org/lkml/2017/4/26/735
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-by: Rusty Russell
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
[1] https://lkml.org/lkml/2017/4/24/7
---
include/linux/kmod.h | 15 --
Suggested-by: Kees Cook
*) Improved documentation.
*) Removed unused code.
# Changes since v1:
*) Renamed module to ModAutoRestrict
*) Improved documentation to explicity refer to module autoloading.
*) Switched to use the new task_security_alloc() hook.
*) Switched from rhash tables to u
On Wed, May 3, 2017 at 6:04 PM, David Howells wrote:
>
> Here are a set of patches to create a mount context prior to setting up a
> new mount, populating it with the parsed options/binary data and then
> effecting the mount.
>
> This allows namespaces and other information to be conveyed through
Hi Serge,
On Thu, May 4, 2017 at 4:58 PM, Serge E. Hallyn wrote:
> On Thu, May 04, 2017 at 03:07:49PM +0200, Djalal Harouni wrote:
>> On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni wrote:
>> > On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski
>> > wrote:
>> [
On Sat, Apr 22, 2017 at 2:17 PM, Djalal Harouni wrote:
> On Sat, Apr 22, 2017 at 1:28 AM, Andy Lutomirski wrote:
[...]
>>
>> My point is that all of these need some way to handle configuration
>> and inheritance, and I don't think that a bunch of per-task prctls is
>
On Tue, May 2, 2017 at 6:33 PM, Andy Lutomirski wrote:
> On Tue, May 2, 2017 at 7:29 AM, Djalal Harouni wrote:
>> On Thu, Apr 27, 2017 at 12:13 AM, Andy Lutomirski wrote:
>>> On Tue, Apr 25, 2017 at 5:23 AM, Djalal Harouni wrote:
>> [...]
>>>> We have to ali
On Thu, Apr 27, 2017 at 12:13 AM, Andy Lutomirski wrote:
> On Tue, Apr 25, 2017 at 5:23 AM, Djalal Harouni wrote:
[...]
>> We have to align procfs and modernize it to have a per mount context
>> where at least the mount option do not propagate to all other mounts,
>> then
Hello Andy,
(Sorry for my late response)
On Thu, Apr 27, 2017 at 12:09 AM, Andy Lutomirski wrote:
> On Tue, Apr 25, 2017 at 5:23 AM, Djalal Harouni wrote:
>> If "limit_pids=1" mount option is set then do not instantiate pids that
>> we can not ptrace. "limit_pi
On Thu, Apr 27, 2017 at 4:07 AM, Rusty Russell wrote:
> Djalal Harouni writes:
>> Hi Rusty,
>>
>> On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell wrote:
>>> Djalal Harouni writes:
>>>> When value is (1), task must have CAP_SYS_MODULE to be able to tri
Hi Rusty,
On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell wrote:
> Djalal Harouni writes:
>> When value is (1), task must have CAP_SYS_MODULE to be able to trigger a
>> module auto-load operation, or CAP_NET_ADMIN for modules with a
>> 'netdev-%s' alias.
>
>
This allows to flush dcache entries of a task on multiple procfs mounts
per pid namespace.
Cc: Kees Cook
Cc: Andy Lutomirski
Signed-off-by: Djalal Harouni
---
fs/proc/base.c| 27 ++-
fs/proc/inode.c | 9 -
fs/proc/root.c
If "limit_pids=1" mount option is set then do not instantiate pids that
we can not ptrace. "limit_pids=1" means that procfs should only contain
pids that the caller can ptrace.
Cc: Kees Cook
Cc: Andy Lutomirski
Signed-off-by: Djalal Harouni
---
fs/proc/base.c | 9
rough procfs on pids with the other syscalls that can be blocked by
seccomp filters.
Later Yama LSM can be updated to check that processes are able only
able to see their children inside /proc/.
[1] https://lkml.org/lkml/2017/3/31/324
Cc: Kees Cook
Suggested-by: Andy Lutomirski
Signed-off-
This is a cleaning patch to add helpers to set and get proc mount
options instead of directly using them. This make it easy to track
what's happening and easy to update in future.
Cc: Kees Cook
Cc: Andy Lutomirski
Signed-off-by: Djalal Harouni
---
fs/proc/base.c
: Kees Cook
Suggested-by: Andy Lutomirski
Signed-off-by: Djalal Harouni
---
fs/locks.c | 6 +++--
fs/proc/base.c | 31 +--
fs/proc/inode.c | 8 +++---
fs/proc/root.c | 65 ++---
fs/proc
, unmounting a private procfs won't clash with other procfs
mounts.
Cc: Kees Cook
Cc: Andy Lutomirski
Signed-off-by: Djalal Harouni
---
fs/proc/base.c| 4 ++--
fs/proc/root.c| 8
fs/proc/self.c| 3 +--
fs/proc/thread_self.c
ch is attached to the current procfs mount.
Suggested-by Andy Lutomirski
*) Do not fill dcache with pid entries that we can not ptrace.
*) Many bug fixes.
Djalal Harouni (6):
[PATCH 1/6] proc: add proc_fs_info struct to store proc information
[PATCH 2/6] proc: move /proc/{self|thread-self} dentrie
On Mon, Apr 24, 2017 at 8:02 PM, Kees Cook wrote:
> On Mon, Apr 24, 2017 at 7:25 AM, Djalal Harouni wrote:
>> On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook wrote:
>>> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski wrote:
>>>> On Fri, Apr 21, 2017 at 5:12 PM, Djala
On Sat, Apr 22, 2017 at 9:29 PM, Kees Cook wrote:
> On Fri, Apr 21, 2017 at 11:51 PM, Andy Lutomirski wrote:
>> On Fri, Apr 21, 2017 at 5:12 PM, Djalal Harouni wrote:
>>> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski wrote:
>>>
[...]
>>> * DCCP use after
dy Lutomirski wrote:
>>>>> On Wed, Apr 19, 2017 at 3:20 PM, Djalal Harouni wrote:
>>>>>> +/* Sets task's modules_autoload */
>>>>>> +static inline int task_set_modules_autoload(struct task_struct *task,
>>>>>
On Sat, Apr 22, 2017 at 2:12 AM, Djalal Harouni wrote:
> On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski wrote:
> [...]
>>>> I personally like my implicit_rights idea, and it might be interesting
>>>> to prototype it.
>>>
>>> I don't like b
On Sat, Apr 22, 2017 at 1:51 AM, Andy Lutomirski wrote:
[...]
>>> I personally like my implicit_rights idea, and it might be interesting
>>> to prototype it.
>>
>> I don't like blocking a needed feature behind a large super-feature
>> that doesn't exist yet. We'd be able to refactor this code into
On Thu, Apr 20, 2017 at 5:02 PM, Ben Hutchings wrote:
> On Thu, 2017-04-20 at 14:44 +0200, Djalal Harouni wrote:
>> > On Thu, Apr 20, 2017 at 4:22 AM, Ben Hutchings
>> > wrote:
>> > On Thu, 2017-04-20 at 00:20 +0200, Djalal Harouni wrote:
>> > [...]
[...]
On Thu, Apr 20, 2017 at 4:22 AM, Ben Hutchings wrote:
> On Thu, 2017-04-20 at 00:20 +0200, Djalal Harouni wrote:
> [...]
>> +modules_autoload:
>> +
>> +A sysctl to control if modules auto-load feature is allowed or not.
>> +This sysctl complements "module
On Thu, Apr 20, 2017 at 12:20 AM, Djalal Harouni wrote:
[...]
> +/* Returns task's modules_autoload */
> +static inline void task_copy_modules_autoload(struct task_struct *dest,
> + struct task_struct *src)
> +{
> + dest->
Hi List,
This is an update of the previous two RFCs that implemented module
auto-load restriction as a stackable LSM [1] [2].
The previous versions were presented as a stackable LSM, this new
version is implemented as a core kernel feature inside the capability
subsystem.
This new version is cle
r
[ 416.040569] Automatic module loading of netdev-tunl0 by "ip"[1398] was denied
[ 416.040578] Automatic module loading of tunl0 by "ip"[1398] was denied
$ cat /proc/sys/kernel/modules_autoload
2
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-by: Kees Cook
Signed-off-by:
"ip"[1362] was denied
Cc: Serge Hallyn
Cc: Andy Lutomirski
Suggested-by: Kees Cook
Signed-off-by: Djalal Harouni
---
Documentation/filesystems/proc.txt | 3 ++
Documentation/prctl/modules_autoload.txt | 49 +++
fs/proc/array.c
On Tue, Apr 11, 2017 at 6:43 AM, Kees Cook wrote:
> On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni wrote:
>> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler
>> wrote:
>>> I think that would be the prudent approach. There is still
>>> the possibility that b
On Tue, Apr 11, 2017 at 9:54 PM, Casey Schaufler wrote:
> On 4/10/2017 9:43 PM, Kees Cook wrote:
>> On Mon, Apr 10, 2017 at 1:00 PM, Djalal Harouni wrote:
>>> On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler
>>> wrote:
>>>> I think that would be the pr
On Tue, Apr 11, 2017 at 6:23 AM, Kees Cook wrote:
> On Sun, Apr 9, 2017 at 3:42 AM, Djalal Harouni wrote:
[...]
>> A userspace request to use a kernel feature that is implemented by modules
>> that are not loaded may trigger the module auto-load feature to load
>> thes
On Mon, Apr 10, 2017 at 9:26 PM, Casey Schaufler wrote:
> On 4/10/2017 11:30 AM, Djalal Harouni wrote:
>> On Mon, Apr 10, 2017 at 5:50 PM, Casey Schaufler
>> wrote:
>>> On 4/9/2017 3:42 AM, Djalal Harouni wrote:
>>>> From: Tetsuo Handa
[...]
>>>
On Mon, Apr 10, 2017 at 9:04 PM, Casey Schaufler wrote:
> On 4/10/2017 11:27 AM, Djalal Harouni wrote:
>> On Mon, Apr 10, 2017 at 5:42 PM, Casey Schaufler
>> wrote:
>>> On 4/9/2017 3:42 AM, Djalal Harouni wrote:
[...]
>>>> --- a/security/security.c
>>
On Mon, Apr 10, 2017 at 5:50 PM, Casey Schaufler wrote:
> On 4/9/2017 3:42 AM, Djalal Harouni wrote:
>> From: Tetsuo Handa
>>
>> Since several modules are planning to use per "struct task_struct" blob,
>> we need a layer for isolating it. Therefore, this p
On Mon, Apr 10, 2017 at 5:42 PM, Casey Schaufler wrote:
> On 4/9/2017 3:42 AM, Djalal Harouni wrote:
[...]
>> +
>> +static inline struct modautoload_task *init_modautoload_task(struct
>> task_struct *tsk,
>> +
On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün wrote:
> A landlocked process has less privileges than a non-landlocked process
> and must then be subject to additional restrictions when manipulating
> processes. To be allowed to use ptrace(2) and related syscalls on a
> target process, a landlock
te all modules which
should be activated.
Signed-off-by: Djalal Harouni
Signed-off-by: Tetsuo Handa
---
include/linux/lsm_hooks.h | 36 +++-
security/security.c | 37 -
2 files changed, 71 insertions(+), 2 deletions(
lue
can not be changed.
*) Access rules:
First the prctl() settings are checked, if the access is not denied
then the global sysctl settings are checked.
Cc: Andy Lutomirski
Cc: James Morris
Cc: Tetsuo Handa
Cc: Kees Cook
Signed-off-by: Djalal Harouni
---
MAINTAINERS
Cc: Andy Lutomirski
Cc: James Morris
Cc: Tetsuo Handa
Cc: Kees Cook
Signed-off-by: Djalal Harouni
---
Documentation/security/00-INDEX| 2 +
Documentation/security/ModAutoRestrict.txt | 77 ++
2 files changed, 79 insertions(+)
create mode 100644
xes and documentation improvements.
All Kees Cook comments handled, except for the removing of
security_kernel_read_file which I will do in next iteration when
I make sure that I did not miss something. Thank you!
Tetsuo Handa (1):
LSM: Allow per LSM module per "struct task_struct&qu
On Thu, Mar 30, 2017 at 9:12 PM, Andy Lutomirski wrote:
> On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote:
>> Hi,
>>
>> This RFC can be applied on top of Linus' tree 89970a04d7
>>
>> This RFC implements support for multiple separate proc instances
On Fri, Mar 31, 2017 at 12:16 AM, Alexey Gladkov
wrote:
> On Thu, Mar 30, 2017 at 05:22:55PM +0200, Djalal Harouni wrote:
>> Hi,
>>
>> This RFC can be applied on top of Linus' tree 89970a04d7
>>
>> This RFC implements support for multiple separate proc inst
On Thu, Mar 30, 2017 at 9:10 PM, Andy Lutomirski wrote:
> On Thu, Mar 30, 2017 at 8:22 AM, Djalal Harouni wrote:
>> This is a preparation patch that adds a proc_fs_info to be able to store
>> different procfs options. Right now some mount options are stored inside
>> the pid
Hi,
This RFC can be applied on top of Linus' tree 89970a04d7
This RFC implements support for multiple separate proc instances inside
the same pid namespace. This allows to solve lot of problems that
today's use case face.
Historically procfs was tied to pid namespaces, and mount options were
pro
This is a preparation patch that adds a proc_fs_info to be able to store
different procfs options. Right now some mount options are stored inside
the pid namespace which make multiple proc share the same mount options.
This patch will help also to fix this.
Signed-off-by: Djalal Harouni
---
fs
This allows to flush dcache entries of a task on multiple procfs mounts
per pid namespace.
Maybe this patch is nedded since this is just an optimization and maybe
it contains bugs.
Signed-off-by: Djalal Harouni
---
fs/proc/base.c| 28 ++--
fs/proc
This is a preparation patch to allow to set and get hidepid and gid
mount options correctly
Signed-off-by: Djalal Harouni
---
fs/proc/base.c | 15 +--
fs/proc/generic.c | 37 +
fs/proc/inode.c | 5 +++--
fs/proc/internal.h
This patch adds support for 'unshare' mount option to have multiple
separated procfs inside the same pid namespace. This allows to solve lot
of problem for containers and their specific use cases.
Signed-off-by: Djalal Harouni
---
fs/proc/generic.c | 10 +
fs/pr
On Wed, Mar 29, 2017 at 1:46 AM, Mickaël Salaün wrote:
> The seccomp(2) syscall can be used by a task to apply a Landlock rule to
> itself. As a seccomp filter, a Landlock rule is enforced for the current
> task and all its future children. A rule is immutable and a task can
> only add new restric
(Cc'ed Kees and Jann for the procfs stacking issue)
On Thu, Mar 23, 2017 at 11:07 PM, Alexey Gladkov
wrote:
> On Thu, Mar 23, 2017 at 05:06:28PM +0100, Djalal Harouni wrote:
>> Hi Alexey,
>>
>> On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
>> wrote:
>>
Hi Alexey,
On Mon, Mar 20, 2017 at 1:58 PM, Alexey Gladkov
wrote:
>
>
> Al Viro, this patch looks better ?
>
> == Overview ==
>
> Some of the container virtualization systems are mounted /proc inside
> the container. This is done in most cases to operate with information
> about the processes. Kn
Signed-off-by: Djalal Harouni
---
fs/locks.c | 6 +-
fs/proc/base.c | 51 +-
fs/proc/generic.c | 5 ++
fs/proc/inode.c | 10 +--
fs/proc/root.c | 181 ++--
fs/proc/self.c |
On Tue, Mar 7, 2017 at 5:24 PM, Andy Lutomirski wrote:
>
> On Mon, Mar 6, 2017 at 3:05 PM, Alexey Gladkov
> wrote:
> >
> > After discussion with Oleg Nesterov I reimplement my patch as an additional
> > option for /proc. This option affects the mountpoint. It means that in one
> > pid namespace
1 - 100 of 276 matches
Mail list logo
