linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Markus Heiser <markus.heiser@darmarit.de>,
	Jani Nikula <jani.nikula@intel.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	"linux-doc@vger.kernel.org Mailing List"
	<linux-doc@vger.kernel.org>
Subject: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
Date: Sat, 22 Oct 2016 17:10:19 -0200	[thread overview]
Message-ID: <20161022171019.0db76837@vento.lan> (raw)
In-Reply-To: <20161022090421.722a6851@lwn.net>

Em Sat, 22 Oct 2016 09:04:21 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> On Sat, 22 Oct 2016 08:56:29 -0200
> Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
> 
> > The security implications will be the same if either coded as an
> > "ioctl()" or as "syscall", the scripts should be audited. Actually,
> > if we force the need of a "syscall" for every such script, we have
> > twice the code to audit, as both the Sphinx extension and the perl
> > script will need to audit, increasing the attack surface.  
> 
> Just addressing this one part for the moment.  Clearly I've not explained
> my concern well.
> 
> The kernel-cmd directive makes it possible for *any* RST file to run
> arbitrary shell commands.  I'm not concerned about the scripts we add, I
> hope we can get those right.  I'm worried about what slips in via a tweak
> to some obscure .rst file somewhere.
> 
> A quick check says that 932 commits touched Documentation/ since 4.8.  A
> lot of those did not come from either my tree or yours; *everybody* messes
> around in the docs tree.  People know to look closely at changes to
> makefiles and such; nobody thinks to examine documentation changes for
> such things. I think there are attackers out there who would like the
> opportunity to run commands in the settings where kernels are built; we
> need to think pretty hard before we make that easier to do.
> 
> See what I'm getting at here?

Yes, I see your point, but IMHO, if we add an extra logic at kernel-cmd to
restrict it to run scripts *only* from an specific directory 
(like Documentation/sphinx), then you'll have a better control.
There were only 37 commits there, from you, me and Jani (and, AFAIKT, all
of them were sent to the linux-doc ML for review):

$ git log --pretty=fuller Documentation/sphinx|grep Commit:|sort|uniq -c
     11 Commit:     Jani Nikula <jani.nikula@intel.com>
     10 Commit:     Jonathan Corbet <corbet@lwn.net>
     16 Commit:     Mauro Carvalho Chehab <mchehab@s-opensource.com>

With is, btw, the same rule we have for a Sphinx extension. 

If you thing this isn't enough, we could also add some logic at
checkpatch.pl to check for the usage of Sphinx extensions.

Thanks,
Mauro

  parent reply	other threads:[~2016-10-22 19:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06  7:20 [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts Markus Heiser
2016-10-06  7:20 ` [PATCH 1/4] doc-rst: " Markus Heiser
2016-10-17 16:46   ` Mauro Carvalho Chehab
2016-10-18  6:07     ` Jani Nikula
2016-10-18  6:52       ` Markus Heiser
2016-10-18  9:13       ` Mauro Carvalho Chehab
2016-10-18  7:03     ` Markus Heiser
2016-10-18  8:59       ` Mauro Carvalho Chehab
2016-10-18 10:06       ` Mauro Carvalho Chehab
2016-10-18 11:36         ` Markus Heiser
2016-10-06  7:20 ` [PATCH 2/4] doc-rst: customize RTD theme; literal-block Markus Heiser
2016-10-06  7:20 ` [PATCH 3/4] doc-rst: migrated media build kernel-cmd directive Markus Heiser
2016-10-06 11:46   ` Mauro Carvalho Chehab
2016-10-06  7:20 ` [PATCH 4/4] doc-rst: remove the kernel-include directive Markus Heiser
2016-10-06  8:42 ` [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts Jani Nikula
2016-10-06 13:31   ` Mauro Carvalho Chehab
2016-10-06 14:21     ` Jani Nikula
2016-10-06 16:50       ` Mauro Carvalho Chehab
2016-10-07  5:56         ` Jani Nikula
2016-10-11  7:26           ` Markus Heiser
2016-10-11 14:28             ` Mauro Carvalho Chehab
2016-10-11 15:34               ` Jani Nikula
2016-10-11 16:06                 ` Markus Heiser
2016-10-11 16:45                   ` Mauro Carvalho Chehab
2016-10-12  6:57                     ` Markus Heiser
2016-10-12  8:20                   ` Jani Nikula
2016-10-21 22:05             ` Jonathan Corbet
2016-10-22 10:56               ` Mauro Carvalho Chehab
2016-10-22 15:04                 ` Jonathan Corbet
2016-10-22 16:46                   ` Markus Heiser
2016-10-22 19:10                   ` Mauro Carvalho Chehab [this message]
2016-10-23 11:20                 ` Mauro Carvalho Chehab

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=20161022171019.0db76837@vento.lan \
    --to=mchehab@infradead.org \
    --cc=corbet@lwn.net \
    --cc=jani.nikula@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    /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).