linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
Date: Tue, 15 Mar 2011 07:18:59 -0700	[thread overview]
Message-ID: <20110315141859.GA19442@kroah.com> (raw)
In-Reply-To: <1300189828.4017.2.camel@mulgrave.site>

On Tue, Mar 15, 2011 at 07:50:28AM -0400, James Bottomley wrote:
> On Mon, 2011-03-14 at 20:09 -0700, Greg KH wrote:
> > On Mon, Mar 14, 2011 at 10:26:05PM -0400, James Bottomley wrote:
> > > On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote:
> > > > > Vasiliy Kulikov (20):
> > > > >  mach-ux500: mbox-db5500: world-writable sysfs fifo file
> > > > >  leds: lp5521: world-writable sysfs engine* files
> > > > >  leds: lp5523: world-writable engine* sysfs files
> > > > >  misc: ep93xx_pwm: world-writable sysfs files
> > > > >  rtc: rtc-ds1511: world-writable sysfs nvram file
> > > > >  scsi: aic94xx: world-writable sysfs update_bios file
> > > > >  scsi: iscsi: world-writable sysfs priv_sess file
> > > > 
> > > > These are still not merged :(
> > > 
> > > OK, so I've not been tracking where we are in the dizzying ride on
> > > security systems.  However, I thought we landed up in the privilege
> > > separation arena using capabilities.  That means that world writeable
> > > files aren't necessarily a problem as long as the correct capabilities
> > > checks are in place, right?
> > 
> > There are no capability checks on sysfs files right now, so these all
> > need to be fixed.
> 
> That statement is true but irrelevant, isn't it?  There can't be
> capabilities within sysfs files because the system that does them has no
> idea what the capabilities would be.  If there were capabilities checks,
> they'd have to be in the implementing routines.

Ah, you are correct, sorry for the misunderstanding.

> I think the questions are twofold:
> 
>      1. Did anyone actually check for capabilities before assuming world
>         writeable files were wrong?

I do not think so as the majority (i.e. all the ones that I looked at)
did no such checks.

>      2. Even if there aren't any capabilities checks in the implementing
>         routines, should there be (are we going the separated
>         capabilities route vs the monolithic root route)?

I think the general consensus is that we go the monolithic root route
for sysfs files in that we do not allow them to be world writable.

Do you have any exceptions that you know of that do these checks?

thanks,

greg k-h

  reply	other threads:[~2011-03-15 14:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-04 12:22 [PATCH 00/20] world-writable files in sysfs and debugfs Vasiliy Kulikov
2011-02-04 12:23 ` [PATCH 01/20] mach-omap2: mux: world-writable debugfs files Vasiliy Kulikov
2011-02-04 20:09   ` Tony Lindgren
2011-02-04 12:23 ` [PATCH 02/20] mach-omap2: pm: world-writable debugfs timer files Vasiliy Kulikov
2011-02-04 20:10   ` Tony Lindgren
2011-02-04 22:53   ` Kevin Hilman
2011-02-04 12:23 ` [PATCH 03/20] mach-omap2: smartreflex: world-writable debugfs voltage files Vasiliy Kulikov
2011-02-04 20:10   ` Tony Lindgren
2011-02-04 22:54   ` Kevin Hilman
2011-02-07  5:33     ` Menon, Nishanth
2011-02-04 12:23 ` [PATCH 04/20] mach-ux500: mbox-db5500: world-writable sysfs fifo file Vasiliy Kulikov
2011-02-04 12:23 ` [PATCH 08/20] mfd: ab3100: world-writable debugfs *_priv files Vasiliy Kulikov
2011-02-04 12:23 ` [PATCH 09/20] mfd: ab3500: world-writable debugfs register-* files Vasiliy Kulikov
2011-02-04 12:23 ` [PATCH 10/20] mfd: ab8500: " Vasiliy Kulikov
2011-02-04 13:11 ` [rtc-linux] [PATCH 00/20] world-writable files in sysfs and debugfs Linus Walleij
2011-03-12 20:23 ` Vasiliy Kulikov
2011-03-14 22:18   ` [Security] " Andrew Morton
2011-03-15  2:26   ` James Bottomley
2011-03-15  3:09     ` [Security] " Greg KH
2011-03-15 11:50       ` James Bottomley
2011-03-15 14:18         ` Greg KH [this message]
2011-03-15 14:25           ` James Bottomley
2011-03-15 16:08         ` Vasiliy Kulikov
2011-03-15 16:32           ` James Bottomley

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=20110315141859.GA19442@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).