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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 13 Sep 2007 11:05:28 -0500 (CDT)
From:	Brent Casavant <bcasavan@....com>
To:	Gabor Gombas <gombasg@...aki.hu>
cc:	linux-kernel@...r.kernel.org
Subject: Re: O_NOLINK for open()

On Thu, 13 Sep 2007, Gabor Gombas wrote:

> On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
> 
> > System V shmem is right out because the IPC key is publicly
> > visible and there is no combination of permissions which
> > will allow sharing the segment with just one other process
> > (or at least just one other user).  To my knowledge Linux's
> > implementation doesn't provide ACLs for SysV shmem.  SGI's
> > proposed XPMEM suffers from the same problems for my purposes.
> 
> SYSV shared memory has the concept of separate creator and owner ID's,
> so you can share the shmem segment between exactly two users. Just use
> IPC_SET and set shm_perm.uid to the user ID of the peer process.

Hmm.  This will work as long as the peer process is running setuid
to it's own unique user.  Excellent idea!  Since I need to make the
program setuid to avoid non-priveleged ptrace attacks, this is a
terrific solution.

> I think your worries about permissions has been cleared by the other
> posts, but there is still a problem: the client may call ftruncate() on
> the file descriptor, and then your daemon will get a nice SIGBUS when it
> tries to access the shared memory. Handling that gracefully may not be
> trivial esp. if your daemon is multi-threaded. SYSV shmem is _much_
> nicer when you want shared memory between unrelated/untrusted processes.

I'm actually not so concerned about the client -- that code will be
trusted as well.  The problem I'm trying to solve is preventing any
non-priveleged code except the server and client from gaining access
to their shared memory area.  With the feedback I've received from
this thread I think a solid design is emerging, some of which will
need to be solved by system configuration by the sysadmin.

Thanks,
Brent

-- 
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/