All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: mmap_file_perms needs ioctl also
Date: Fri, 9 Mar 2007 09:06:47 -0800 (PST)	[thread overview]
Message-ID: <760182.67627.qm@web36602.mail.mud.yahoo.com> (raw)
In-Reply-To: <1173444689.3241.82.camel@moss-spartans.epoch.ncsc.mil>


--- Stephen Smalley <sds@tycho.nsa.gov> wrote:

 
> ioctl permission is effectively useless as it
> doesn't distinguish
> read-flow vs. write-flow vs. control-op, so it ends
> up being allowed
> pervasively whenever you allow read or write.  We
> really need to just
> replace it (ala the attempts by Lorenzo in the
> past), but doing so
> compatibly won't be easy.

That is a significant understatement. Ioctl is
used, misused, and abused so many different ways
in so many places that doing a granular enforcement
may be beyond the current state of the art and is
certainly a maintenance burden that exceeds the
scope of the existing SELinux implementation.
An investigation into the networking drivers alone
ought to send the rational programmer running in
blind terror. Then there are the graphics
implementations.

I suggest that an approach that would add more
value to the kernel overall and make someone a
minor kernel diety would be to replace the ioctl
mechanism completely. I also think that it would
be less work than trying to do a proper job of
granualizing the existing smoldering pile of
technology.

We did look into the granular ioctl security
policy issue in Unix in the 20th centuty. If
you restrict your system to a very limited set
of devices it still stretches an evaluation
budget beyond the breaking point. It's very
hard to justify the value of the granularity
in terms of the cost.



Casey Schaufler
casey@schaufler-ca.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  parent reply	other threads:[~2007-03-09 17:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-08 15:27 mmap_file_perms needs ioctl also Daniel J Walsh
2007-03-09  7:38 ` Russell Coker
2007-03-09 12:51   ` Stephen Smalley
2007-03-09 12:57     ` Daniel J Walsh
2007-03-09 17:06     ` Casey Schaufler [this message]
2007-03-09 17:14       ` Stephen Smalley

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=760182.67627.qm@web36602.mail.mud.yahoo.com \
    --to=casey@schaufler-ca.com \
    --cc=selinux@tycho.nsa.gov \
    /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.