Signed-off-by: Vasily Kulikov
---
include/linux/poison.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/linux/poison.h b/include/linux/poison.h
index a721bcd..4a27153 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -73,10 +73,6 @@
#define ATM_POISON_FREE
TIMER_ENTRY_STATIC and TAIL_MAPPING are defined as poison pointers which
should point to nowhere. Redefine them using POISON_POINTER_DELTA arithmetics
to make sure they really point to non-mappable area declared by the
target architecture.
Signed-off-by: Vasily Kulikov
---
include/linux
exhausted.
Changing it to a smaller value solves the problem for small
mmap_min_addr setups.
The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6
Signed-off-by: Vasily Kulikov
---
include/linux/poison.h | 4 ++--
1 file changed, 2 insertions(+), 2 dele
it to a smaller value solves the problem for small
mmap_min_addr setups.
The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6
Signed-off-by: Vasily Kulikov seg...@openwall.com
---
include/linux/poison.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
TIMER_ENTRY_STATIC and TAIL_MAPPING are defined as poison pointers which
should point to nowhere. Redefine them using POISON_POINTER_DELTA arithmetics
to make sure they really point to non-mappable area declared by the
target architecture.
Signed-off-by: Vasily Kulikov seg...@openwall.com
Signed-off-by: Vasily Kulikov seg...@openwall.com
---
include/linux/poison.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/linux/poison.h b/include/linux/poison.h
index a721bcd..4a27153 100644
--- a/include/linux/poison.h
+++ b/include/linux/poison.h
@@ -73,10 +73,6
Hi,
Any feedback?
On Thu, May 14, 2015 at 14:07 +0300, Vasily Kulikov wrote:
> This is a raw version of the patch inspired by the discussion:
> http://www.openwall.com/lists/oss-security/2015/05/02/6.
>
> The patch tries to achieve two goals:
> 1) Move "overflowed&
Hi,
Any feedback?
On Thu, May 14, 2015 at 14:07 +0300, Vasily Kulikov wrote:
This is a raw version of the patch inspired by the discussion:
http://www.openwall.com/lists/oss-security/2015/05/02/6.
The patch tries to achieve two goals:
1) Move overflowed poison pointers out of the mmap'able
This is a raw version of the patch inspired by the discussion:
http://www.openwall.com/lists/oss-security/2015/05/02/6.
The patch tries to achieve two goals:
1) Move "overflowed" poison pointers out of the mmap'able memory zone
2) Simplify addition of new poison pointers
The current 0x00200200
This is a raw version of the patch inspired by the discussion:
http://www.openwall.com/lists/oss-security/2015/05/02/6.
The patch tries to achieve two goals:
1) Move overflowed poison pointers out of the mmap'able memory zone
2) Simplify addition of new poison pointers
The current 0x00200200
On Thu, May 29, 2014 at 16:53 +0400, Pavel Emelyanov wrote:
> On 05/29/2014 03:59 PM, Vasily Kulikov wrote:
> > On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
> >> On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
> >>> On Thu, May 29, 2014 at 13:0
On Thu, May 29, 2014 at 16:53 +0400, Pavel Emelyanov wrote:
On 05/29/2014 03:59 PM, Vasily Kulikov wrote:
On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
On 05/29/2014 09
On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
> On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
> > On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
> >> On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
> >>> On Wed, May 28, 2014 at 23:2
On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
> On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
> > On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
> > ] We need a direct method of getting the pid inside containers.
> > ] If some issues occurred inside
On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
> On 05/28/2014 10:28 PM, Vasily Kulikov wrote:
> > On Wed, May 28, 2014 at 16:44 +0400, Pavel Emelyanov wrote:
> > It will be simplier
> > to parse the file -- if 'ns_ids' file contains some ID then this ID
On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
On 05/28/2014 10:28 PM, Vasily Kulikov wrote:
On Wed, May 28, 2014 at 16:44 +0400, Pavel Emelyanov wrote:
It will be simplier
to parse the file -- if 'ns_ids' file contains some ID then this ID for
every ns can be obtained
On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
] We need a direct method of getting the pid inside containers.
] If some issues occurred inside container guest, host user
On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
] We need
hanged;
> >
> > b) In one pidns, will tell the pid inside containers:
> > NStgid: 16289 3
> > NSpid: 16289 3
> > ** Process id is 1628 in level 0, 9 in level 1, 3 in level 2.
> >
> > c) If pidns is nested, it depends on which pidns
9 3
** Process id is 1628 in level 0, 9 in level 1, 3 in level 2.
c) If pidns is nested, it depends on which pidns are you in.
NStgid: 9 3
NSpid: 9 3
** Views from level 1
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing security into open
Hi Chen,
On Mon, May 26, 2014 at 18:05 +0800, Chen Hanxiao wrote:
> We need a direct method of getting the pid inside containers.
> If some issues occurred inside a container guest, host user
> could not know which process is in trouble just by guest pid:
> the users of container guest only knew
Hi Chen,
On Mon, May 26, 2014 at 18:05 +0800, Chen Hanxiao wrote:
We need a direct method of getting the pid inside containers.
If some issues occurred inside a container guest, host user
could not know which process is in trouble just by guest pid:
the users of container guest only knew the
es have?
Also, an orthogonal addition: you might want to keep only minimum
information about capabilities or something -- keep only cap_t field in
namespace structure without explicit kernel thread for each ns. When UMH is
created, just fill the required caps in it.
Thanks,
--
Vasily K
: you might want to keep only minimum
information about capabilities or something -- keep only cap_t field in
namespace structure without explicit kernel thread for each ns. When UMH is
created, just fill the required caps in it.
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing
amp;& !(fs->fs_flags & FS_HAS_SUBTYPE)) {
Maybe we should divide request_module() into several functions regarding
expected caller's privileges?
- request_module() for CAP_SYS_MODULE in init_ns
- request_module_relaxed() for everybody
request_module_relaxed() is used in get_fs_type(), dev_load()
,
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
init(1).
Probably it worth noting here that this is true unless
prctl() with PR_SET_CHILD_SUBREAPER option is called.
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
that this is true unless
prctl() with PR_SET_CHILD_SUBREAPER option is called.
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
nesteuser namespaces before this change running my test
> program causes the kernel to die a horrible death. With 10,000,000
> nested user namespaces after this change my test program runs to
> completion and causes no harm.
>
> Pointed-out-by: Vasily Kulikov
> Signed-off-by: &
program causes the kernel to die a horrible death. With 10,000,000
nested user namespaces after this change my test program runs to
completion and causes no harm.
Pointed-out-by: Vasily Kulikov seg...@openwall.com
Signed-off-by: Eric W. Biederman ebied...@xmission.com
Looks sane, thanks.
Acked
t file rwx bits?
>
> I'd like comments. I'll cc LSM on any future replies to that thread...
Why does application need it? Why does anybody but admin need this
information?
Probably this may be implemented as root-only audit messages? Or
introduce new NETLINK_EPERMREASON netlink family?
--
like comments. I'll cc LSM on any future replies to that thread...
Why does application need it? Why does anybody but admin need this
information?
Probably this may be implemented as root-only audit messages? Or
introduce new NETLINK_EPERMREASON netlink family?
--
Vasily Kulikov
http
bably worth noting in Documentation/ too.
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
ide LSM changes and the core security
subsystem itself targeted on multiple LSMs which divides LSM
implementations (which might be not very important for someone) and the core
architecture (which is important for everybody).
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing security i
on multiple LSMs which divides LSM
implementations (which might be not very important for someone) and the core
architecture (which is important for everybody).
Thanks,
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe from this list: send
space solution, in which case you
may as well do everything in user space.
[...]
You should also update Documentation/security/LSM.txt with new security=
rules and rules of LSM stacking limitations. Motivation of stacking is
probably worth noting in Documentation/ too.
Thanks,
--
Vasily
() moves ->input_pkt_queue to
->process_queue and calls __netif_receive_skb(), which does all networking
stack magic.
AFAICS, one could create user_ns, net_ns inside of it, and setup routing
tables and netfilter to infinitely pass few network packets from and to
veth, abusing ksoftirq.
-
networking
stack magic.
AFAICS, one could create user_ns, net_ns inside of it, and setup routing
tables and netfilter to infinitely pass few network packets from and to
veth, abusing ksoftirq.
--
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe
On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
> Vasily Kulikov writes:
>
> > Currently there is completely no limiting in number of user namespaces
> > created by unprivileged users. One can freely create thousands of
> > user_ns'es and exhaust kernel mem
On Fri, Dec 28, 2012 at 18:43 +, Al Viro wrote:
> On Fri, Dec 28, 2012 at 09:56:27PM +0400, Vasily Kulikov wrote:
> > The included patch is a basic fix for both or them. Both values are
> > hardcoded here to 100 max depth and 1000 max in total. I'm not sure how
> >
I suppose the issue is not
veth-specific, almost all newly available for unprivileged users code
pathes are vulnerable to DoS attacks.
Signed-off-by: Vasily Kulikov
--
include/linux/sched.h |3 +++
kernel/user_namespace.c | 26 ++
2 files changed, 29 insertion
the issue is not
veth-specific, almost all newly available for unprivileged users code
pathes are vulnerable to DoS attacks.
Signed-off-by: Vasily Kulikov seg...@openwall.com
--
include/linux/sched.h |3 +++
kernel/user_namespace.c | 26 ++
2 files changed, 29
On Fri, Dec 28, 2012 at 18:43 +, Al Viro wrote:
On Fri, Dec 28, 2012 at 09:56:27PM +0400, Vasily Kulikov wrote:
The included patch is a basic fix for both or them. Both values are
hardcoded here to 100 max depth and 1000 max in total. I'm not sure how
better to make them configurable
On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
Vasily Kulikov seg...@openwall.com writes:
Currently there is completely no limiting in number of user namespaces
created by unprivileged users. One can freely create thousands of
user_ns'es and exhaust kernel memory without
On Sat, Aug 11, 2012 at 23:34 -0700, Kees Cook wrote:
> On Wed, Aug 8, 2012 at 5:19 AM, Vasily Kulikov wrote:
> > Hi Kees,
> >
> > On Wed, Jul 25, 2012 at 17:29 -0700, Kees Cook wrote:
> >> +/**
> >> + * safe_hardlink_source - Check for safe hardlink condi
On Sat, Aug 11, 2012 at 23:34 -0700, Kees Cook wrote:
On Wed, Aug 8, 2012 at 5:19 AM, Vasily Kulikov seg...@openwall.com wrote:
Hi Kees,
On Wed, Jul 25, 2012 at 17:29 -0700, Kees Cook wrote:
+/**
+ * safe_hardlink_source - Check for safe hardlink conditions
+ * @inode: the source
Hi Kees,
On Wed, Jul 25, 2012 at 17:29 -0700, Kees Cook wrote:
> +/**
> + * safe_hardlink_source - Check for safe hardlink conditions
> + * @inode: the source inode to hardlink from
> + *
> + * Return false if at least one of the following conditions:
> + *- inode is not a regular file
> + *
Hi Kees,
On Wed, Jul 25, 2012 at 17:29 -0700, Kees Cook wrote:
+/**
+ * safe_hardlink_source - Check for safe hardlink conditions
+ * @inode: the source inode to hardlink from
+ *
+ * Return false if at least one of the following conditions:
+ *- inode is not a regular file
+ *-
__neigh_create() returns either a pointer to struct neighbour or PTR_ERR().
But the caller expects it to return either a pointer or NULL. Replace
the NULL check with IS_ERR() check.
The bug was introduced in a263b3093641fb1ec377582c90986a7fd0625184.
Signed-off-by: Vasily Kulikov
---
Compile
__neigh_create() returns either a pointer to struct neighbour or PTR_ERR().
But the caller expects it to return either a pointer or NULL. Replace
the NULL check with IS_ERR() check.
The bug was introduced in a263b3093641fb1ec377582c90986a7fd0625184.
Signed-off-by: Vasily Kulikov seg
50 matches
Mail list logo
