linux-kernel - Re: O_NOATIME and files in /proc

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] [day] [month] [year] [list]

Date:	Mon, 30 Nov 2009 11:36:00 +0100
From:	Bernd Petrovitsch <bernd@...mix.at>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>, drepper@...il.com
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: O_NOATIME and files in /proc

On Fri, 2009-11-20 at 22:11 +0000, Alan Cox wrote:
> On Fri, 20 Nov 2009 13:36:51 -0800
> Andrew Morton <akpm@...ux-foundation.org> wrote:
> > On Tue, 17 Nov 2009 18:06:29 +0100
> > Bernd Petrovitsch <bernd@...mix.at> wrote:
[...]
> > > Is there a specific reason that open can not open files (at
> > > least /proc/noatime and /proc/cpuinfo) under /proc with NO_ATIME as the
> > > following program shows:
> 
> Andreww: http://lkml.org/lkml/2004/6/14/184 seems to explain the origin
> of this. To follow it further you'd need to discuss it with Ulrich I
What is the best to reach him?
Via drepper@...il.com?

> imagine and see why glibc expected that behaviour and in turn where it
> came from and what security or similar concerns were anticipated.
Security reasons were the only issues I found there (and no links to
further papers/articles/motivation/literature).

For the more technical side (of the security concerns):
- I agree that it may be important to forcibly keep the atime (for files
  of other users including root) - at least for backups[0].
  However, I stumbled over it because I needed a file which changes
  over time for some periodic (as in every second) application
  and /proc/uptime was the first crossing my mind[1].
  Said application used O_NOATIME on each open() as it doesn't hurt
  anyways (and saves a little I/O - God knows how the root on the
  customers systems mounts filesystems).
  So the better solution in this case would have been to e.g. simply
  ignore the O_NOATIME flag (but make the open succeed). Yes, that
  can be solved in userspace too with a minimal wrapper function.

- *if* root (or whoever mounted it) already set "noatime" on a
  filesystem, the atime won't be updated anyways. So I can't see any
  security concern if the open() also requests O_NOATIME as it is not
  any change in behaviour.
  And since /proc/mounts is readable by any user, the user knows it.

- for procfs (and thus /proc): That seems to not store atime at all but
  returns always the "current" time.
  So I fail to see what rejecting O_NOATIME on procfs (for files of
  other users including root) may achieve.
  Perhaps it makes sense to judge this on a per-file basis.

Alas, perhaps selinux, capabilities and similar may invalid the above
thoughts (but I don't know enough of these extensive security frameworks
to comment on that).

	Bernd

[0]: I don't value "it can be proofed that user read the file" that
     much. Just knowing that a user open a given file doesn't imply that
     he actually read and actually understood it. Perhaps the user just
     misclicked the file and exited the filereader 0.5s after opening
     it.
[1]: Yes, that can also be solved differently - just more cumbersome.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


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