[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8A543634-BA18-48ED-A32C-3F44F3BFD11F@gmail.com>
Date: Wed, 2 Nov 2016 11:00:20 -0400
From: Dave Tian <dave.jing.tian@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: Legitimate use of /proc/PID/mem,maps and smaps
> On Nov 1, 2016, at 11:42 PM, Marian Marinov <mm-l@...u.biz> wrote:
>
> Hi guys,
> after dirtyCoW me and colleges of mine started discussing different vectors of exploiting applications and we noticed that a lot of the exploits we were discussing relied on /proc/PID/mem or mpas or smaps to be readable by the same user.
>
> We started thinking of legitimate use of these files (lsof, gdb with plugins and valgrind). Are there any other legitimate users of these files, maybe X?
>
> I'm considering writing a patch, which will make sure that nobody, even the owner of the process, can't open these files and only root or users with CAP_DAC_OVERRIDE and/or CAP_SYS_ADMIN can see these files.
> For everyone that is not root and lacks DAC_OVERRIDE and SYS_ADMIN the files should not exists.
>
> What do you think about this?
>
> Best regards,
> Marian
I do not see a problem of a process looking into its own address space. The root cause of dirtycow is not the permission of accessing /proc/self/mem, which only provides a trigger, same as ptrace(), but the race condition between the cowed page and unmmap, although I do agree if there is a better/reasonable way to limit the attack surface, just like limiting perf, without breaking user-space tools.
-daveti
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
