linux-kernel - Re: O_NOLINK for open()

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: <20070912180937.Y5573@pkunk.americas.sgi.com>
Date:	Wed, 12 Sep 2007 18:27:52 -0500 (CDT)
From:	Brent Casavant <bcasavan@....com>
To:	Al Viro <viro@....linux.org.uk>
cc:	linux-kernel@...r.kernel.org
Subject: Re: O_NOLINK for open()

On Wed, 12 Sep 2007, Al Viro wrote:

> On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
> 
> > P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
> >      files.  That might be an additional nicety -- programs worried about
> >      being snooped could unlink their own entry.  /dev/mem and /dev/kmem
> >      can simply be removed by the sysadmin of such a system.  If all of
> >      that were done you'd have to resort to attacking crash dumps, core
> >      dumps, or via something like kdb to extract "hidden" data.
> 
> Give me a break.  And learn about ptrace(2).  This "unlinking" bullshit
> buys you zero additional security, both for /proc/*/mem and for /dev/mem
> (see mknod(2)).

Yes, I fully understand that mknod can recreate the nodes -- however
only the superuser can do so, and if the superuser is attacking a
process all bets are off anyway.  OK, so /dev/*mem isn't to worry
about, since it's already owned by root.  Still, /proc/#/mem is owned
by the user, not root, leaving it potentially open to inspection by
third party processes.

I'm thinking out loud.  Sorry to cause any grief.

My (limited) understanding of ptrace is that a parent-child
relationship is needed between the tracing process and the traced
process (at least that's what I gather from the man page).  This
does give cause for concern, and I might have to see what can be
done to alleviate this concern.  I fully realize that making this
design completely unassilable is a fools errand, but closing off
as many attack vectors as possible seems prudent.

-- 
Brent Casavant                          All music is folk music.  I ain't
bcasavan@....com                        never heard a horse sing a song.
Silicon Graphics, Inc.                    -- Louis Armstrong
-
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/