All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Mason <ric.masonn@gmail.com>
To: Luigi Semenzato <semenzato@google.com>
Cc: linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
	Hugh Dickins <hughd@google.com>
Subject: Re: security: restricting access to swap
Date: Fri, 15 Mar 2013 17:04:17 +0800	[thread overview]
Message-ID: <5142E411.2040005@gmail.com> (raw)
In-Reply-To: <CAA25o9RchY2AD8U30bh4H+fz6kq8bs98SUrkJUkTpbTHSGjcGA@mail.gmail.com>

On 03/12/2013 07:57 AM, Luigi Semenzato wrote:
> Greetings linux-mmers,
>
> before we can fully deploy zram, we must ensure it conforms to the
> Chrome OS security requirements.  In particular, we do not want to
> allow user space to read/write the swap device---not even root-owned
> processes.

Interesting.

>
> A similar restriction is available for /dev/mem under CONFIG_STRICT_DEVMEM.

Sorry, what's /dev/mem used for?  and why relevant your topic?

>
> There are a few possible approaches to this, but before we go ahead
> I'd like to ask if anything has happened or is planned in this
> direction.
>
> Otherwise, one idea I am playing with is to add a CONFIG_STRICT_SWAP
> option that would do this for any swap device (i.e. not specific to
> zram) and possibly also when swapping to a file.  We would add an
> "internal" open flag, O_KERN_SWAP, as well as clean up a little bit
> the FMODE_NONOTIFY confusion by adding the kernel flag O_KERN_NONOTIFY
> and formalizing the sets of external (O_*) and internal (O_KERN_*)
> open flags.
>
> Swapon() and swapoff() would use O_KERN_SWAP internally, and a device
> opened with that flag would reject user-level opens.
>
> Thank you in advance for any input/suggestion!
> Luigi
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2013-03-15  9:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-11 23:57 security: restricting access to swap Luigi Semenzato
2013-03-12 13:06 ` Konrad Rzeszutek Wilk
2013-03-12 15:46   ` Luigi Semenzato
2013-03-12 23:32 ` Simon Jeons
2013-03-15  9:04 ` Ric Mason [this message]
2013-03-15 15:48   ` Luigi Semenzato
2013-03-15 16:55     ` Johannes Weiner
2013-03-15 17:27       ` Luigi Semenzato
2013-03-15 22:19         ` Luigi Semenzato
2013-03-18  3:58 ` Hugh Dickins
2013-03-18 16:05   ` Luigi Semenzato
2013-03-18 23:43 ` KOSAKI Motohiro
2013-03-19 17:39   ` Will Drewry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5142E411.2040005@gmail.com \
    --to=ric.masonn@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=semenzato@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.