Seahorse issues

[M. Warner Losh]

In message: <1208024491.1327.5.camel at localhost>
            Coleman Kane <cokane at freebsd.org> writes:
: On Sat, 2008-04-12 at 13:51 -0400, Joe Marcus Clarke wrote:
: > On Sat, 2008-04-12 at 13:38 -0400, Joe Marcus Clarke wrote:
: > > On Sat, 2008-04-12 at 12:43 -0400, Coleman Kane wrote:
: > > > 
: > > > As for the mlock() privilege issue, I am not sure what we'll do about
: > > > that. It would be nice, at some point, to support that feature for
: > > > normal users. As long as I'm diligent about my swap-space, etc... and
: > > > access to my workstation, I'm *pretty* secure. Things like common-use
: > > > lab computers, etc... are probably more appropriate for this feature.
: > > 
: > > Since we already have an rlimit for locked memory (RLIMIT_MEMLOCK), and
: > > it is used by the mlock(2) syscall, what about the attached patch to add
: > > a sysctl to control user access to mlock (but not allowing mlockall(2))?
: > > This has been tested to fix the gnome-keyring issue when the sysctl is
: > > set to 1.  If this is agreeable, I can add some manpage docs as well.
: > 
: > Minor modification to allow munlock(2) as well as mlock(2).
: > 
: > http://www.marcuscom.com/downloads/vm_mmap.c.diff
: > 
: > Joe
: > 
: 
: I've reviewed these patches, and also read up on the Linux 2.6.9+
: implementation, as well as referred to various documentations about it.
: I'd like to float an email to current@ and see what comes up there
: regarding unprivileged mlock(2). There might already be a "more proper"
: approach that just isn't being employed.
: 
: The one thing that worries me is whether or not this could be used by a
: local user to bring about a DoS on a machine. I *think* that, if you set
: the hard limit during startup, then enforce a good soft-limit, then
: you'll be pretty safe.
: 
: Anyhow, I'll see what sort of comments I can get.

At the very least we'd have to change the defaults:

  memorylocked     infinity kB

I'm not sure where else this rlimit is used, so some careful study may
be needed.  Before people are going to be comfortable allowing this
in, you'll need to say that this limit is used for A B C now and
mlock() usage is similar to it in this way or that way and what the
potential for local DoS is with any change...

I'm also not sure I like the sysctl part, but I'll defer to others on
that...

Warner