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
et 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(+)
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" p
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 po
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, Pa
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
> >
> > a) In init_pid_ns, nothing changed;
> >
> > 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.
> >
> >
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 t
t semantic should UMH privileges 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
&& fs && !(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
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
With 1000 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
; Was it 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 n
s
probably 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 majo
tive as you divide 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 - brin
ss_backlog() 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 ks
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 kerne
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
>
as this user scheduler time. 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 ++
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
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
25 matches
Mail list logo
