linux-kernel - Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map

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: <20110914144841.GA7906@albatros>
Date:	Wed, 14 Sep 2011 18:48:41 +0400
From:	Vasiliy Kulikov <segoon@...nwall.com>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Pavel Machek <pavel@....cz>, Andrew Morton <akpm00@...il.com>,
	linux-kernel@...r.kernel.org, containers@...ts.osdl.org,
	linux-fsdevel@...r.kernel.org,
	Kirill Shutemov <kirill@...temov.name>,
	Pavel Emelyanov <xemul@...allels.com>,
	James Bottomley <jbottomley@...allels.com>,
	Nathan Lynch <ntl@...ox.com>, Zan Lynx <zlynx@....org>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Tejun Heo <tj@...nel.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/
 directory v12

Hi,

On Wed, Sep 14, 2011 at 17:44 +0400, Cyrill Gorcunov wrote:
> On Wed, Sep 14, 2011 at 03:39:12PM +0400, Cyrill Gorcunov wrote:
> ...
> > > 
> > > AFAICT, this recreates existing problem with /proc/<pid>/fd (see
> > > discussion at 
> > > 
> > > http://www.securityfocus.com/archive/1/507386/30/0/threaded
> > > 
> > > ). It creates object that looks like symlink, but does not behave as
> > > one, and permissions of directories are not checked as they would be
> > > if it was a symlink.

The only difference between fd/X and dup(X) was the ability to write to
an fd opened as RO.  Now it is fixed:

$ ls -l 123
-rw-r--r-- 1 vasya vasya 0 Sep 14 18:21 123
$ id
uid=1008(new1) gid=1008(new1) groups=1008(new1)
$ bash 4< /tmp/123
new1@...atros:/tmp$ echo bla >&4
bash: 4: Bad file descriptor
new1@...atros:/tmp$ echo bla >/proc/$$/fd/4
bash: /proc/8527/fd/4: Permission denied

I don't really see any difference between opening fd/* and dup'ing file
descriptors with the current code.


> So, there is no *new* hole.

Actually now I see the difference between having something mapped and
having an _fd_ of this something.

Relevant code:

+static struct dentry *
+proc_map_files_instantiate(struct inode *dir, struct dentry *dentry,
+              struct task_struct *task, const void *ptr)
+{
...
+   inode->i_mode = S_IFLNK;
+
+   if (file->f_mode & FMODE_READ)
+       inode->i_mode |= S_IRUSR | S_IXUSR;
+   if (file->f_mode & FMODE_WRITE)
+       inode->i_mode |= S_IWUSR | S_IXUSR;


If you have a write mmap area, but no fd, you may not trunc a file; with
map_files/ you may get an fd and ftrunc it.


> Both fd/ and map_files/ have ptrace_may_access checks, which
> (as you pointed) might be not enough, but squashing all changes
> into one big path seems to be not that good idea.

ptrace() check is irrelevant to the access bypasses by the task owner.

> Vasiliy, as far as I remember you had something in mind on
> fd/ additional fixups, no?

Only closing fd presense leak:

http://www.openwall.com/lists/kernel-hardening/2011/09/10/3
http://www.openwall.com/lists/kernel-hardening/2011/09/10/4

Unfortunatelly, not yet applied/commented :(

Thanks,

-- 
Vasiliy 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/