linux-kernel - Re: [RFC 1/1] LSM ptags: Add tagging of processes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1480324296.2089.1.camel@nonadev.net>
Date:   Mon, 28 Nov 2016 10:11:36 +0100
From:   José Bollo <jobol@...adev.net>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC 1/1] LSM ptags: Add tagging of processes

Le samedi 26 novembre 2016 à 13:25 +0900, Tetsuo Handa a écrit :
> Jose Bollo wrote:
> > +/**
> > + * is_valid_utf8 - Is buffer a valid utf8 string?
snip
> Do we really need to check UTF-8 inside kernel? What do you do if
> people start using UTF-32 in the future? There was a discussion
> about use of encoding inside kernel started at
> http://lkml.kernel.org/r/20071103164303.GA26707@ubuntu .

Hello Tetsuo-san,

First, thank you for your bright review.

I followed that first thread a lot and conclude to remove that check in
favour of just prohibiting nul bytes that otherwise could create
problems.

snip
> > +
> > +	if (size > INT_MAX)
> > +		return -E2BIG;
> 
> This sanity check is useless. INT_MAX is 2,147,483,647 but kmalloc()
> can't
> allocate larger than 8,388,608 bytes if PAGE_SIZE = 4096 and
> MAX_ORDER = 11.
> 
> > +	buffer = kmalloc(size, GFP_KERNEL);
> > +	if (!buffer)
> > +		return -ENOMEM;
> 
> Moreover, kmalloc() will not try to allocate larger than 32,768 bytes
> (PAGE_ALLOC_COSTLY_ORDER = 3). Although __GFP_NOFAIL can force
> kmalloc() to
> retry by invoking the OOM killer, such behavior might change in near
> future
> due to http://lkml.kernel.org/r/20161123064925.9716-3-mhocko@kernel.o
> rg .
> 
> Given these constants
> 
> #define MAXCOUNT	4000
> #define MAXTAGLEN	4000
> #define MAXVALUELEN	32700
> 
> and someone tried to use as many and long as possible tags, what is
> possible max value for "size"? I think that that value can easily
> exceed
> 32,768 and kmalloc() won't be reliable. vmalloc() can be used as a
> fallback
> when kmalloc() failed, but is trying to pass possible max value for
> "size"
> to vmalloc() reasonable? Shouldn't this function be rewritten not to
> allocate so much memory?
> 
> Also, how much memory will be consumed if everybody tried to use tags
> as many and long as possible?

The fact is that ptags is seat behind the implementation of the special
files in /proc/PID/attr/.. Thus, it has to return an allocated buffer.
I'm not aware of what kind of allocation is possible to use for this
subsystem. Is it possible to use vmalloc? I dont know.

However, the remark is not just about how to implement it technically.
It is also about what amount of memory ptags could consume for threads.

My first naive idea is that consumers of ptags are reasonnables. Am I
fool, crazy or utopian? Guess...

I'm in favour of having a guard. And the gurad of a given memory size
seems good to my eyes. I could rewrite to enforce at most the use of
say 32700 characters. It could be enough for most interesting usage and
conversely it would fit the memory requirement that you pointed out.

Thanks again

Best regards
José