All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: Russell Coker <russell@coker.com.au>
Cc: SE-Linux <selinux@tycho.nsa.gov>
Subject: Re: temporary hack to use udev in selinux
Date: Sun, 1 Aug 2004 13:03:57 +0100	[thread overview]
Message-ID: <20040801120357.GG7384@lkcl.net> (raw)
In-Reply-To: <200408012031.37581.russell@coker.com.au>

On Sun, Aug 01, 2004 at 08:31:37PM +1000, Russell Coker wrote:
> On Sun, 1 Aug 2004 02:35, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > On Sat, Jul 31, 2004 at 11:43:19AM +1000, Russell Coker wrote:
> > > On Fri, 30 Jul 2004 06:09, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > > > The patch allows for getxattr/setxattr, but still doesn't address the
> > > > issue of SELinux treating different instances of tmpfs in different
> > > > ways.  That why we need mount option support.  It may be sufficient to
> > > > just extend fscontext= semantics (set superblock security context)
> > > > beyond xattr-supporting filesystems, so that we can assign a different
> > > > superblock security context to each instance and then set up type
> > > > transition rules appropriately, using fs_use_trans in all cases for the
> > > > initial labeling.
> > >
> > > This shouldn't even need kernel code.  As long as the default type is not
> > > overly permissive the mount program can relabel the root directory of a
> > > tmpfs file system after mounting it.
> >
> >  stephen i believe is concerned that tmpfs_t, because it is used for
> >  two different purposes, is used for filesystems both shmfs and tmpfs,
> >  and, prior to this patch, nobody cared because they never used one
> >  of those [tmpfs].
> 
> Yes.  So we need to have different mounts of the shmfs get different types.
> 
> >  what _you_ are saying, russell, is that instead of increasing the
> >  permissions on the usage of tmpfs_t, is to mount a tmpfs mountpoint,
> >  then run setfiles on its contents prior to use, such that it will
> >  never be necessary to increase the permissions of tmpfs_t?
> 
> Yes.  In fact using tmp_t as the label on the root directory of /dev/shm so 
> that file/directory creation gets the same labels as it does under /tmp, 
> while we leave tmpfs_t with restrictive access.
 
 eek.

 okay... *scared*.

 why, because i need this _today_ :)

 i need usb-mount, therefore i need udev, therefore i need this
 patch, therefore i need to do this now.

 okay.  so i just.. okayokay.

 i can just change, in /etc/selinux/src/fs_use, the line
 that says something like fs_trans shm .... tmpfs_t to
 say tmp_t?

 well, hey, i can always try it.

 i have had to add _stacks_ of permissions to tmpfs_t to get udev,
 initrc_t, hotplug_t and fsadm_t _and_ then some to get this to work
 (on to about the 10th reboot so far!).

 presumably i can just ":%s/tmpfs_t/tmp_t/g" with vi and, well other
 than some duplicates, expect it to... work?

 all very non-scientific and i DON'T CARE! :)

 l.


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

  reply	other threads:[~2004-08-01 11:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-28 23:20 temporary hack to use udev in selinux Luke Kenneth Casson Leighton
2004-07-29  0:29 ` Joshua Brindle
2004-07-29  0:57   ` Luke Kenneth Casson Leighton
2004-07-29  1:35   ` Luke Kenneth Casson Leighton
2004-07-29  2:04     ` Luke Kenneth Casson Leighton
2004-07-29 12:47       ` Stephen Smalley
2004-07-29 14:20         ` Luke Kenneth Casson Leighton
2004-07-29 16:57           ` Stephen Smalley
2004-07-29 17:06             ` James Morris
2004-07-29 17:22               ` Stephen Smalley
2004-07-29 20:05                 ` Luke Kenneth Casson Leighton
2004-07-29 20:09                   ` Stephen Smalley
2004-07-31  1:43                     ` Russell Coker
2004-07-31 16:35                       ` Luke Kenneth Casson Leighton
2004-08-01 10:31                         ` Russell Coker
2004-08-01 12:03                           ` Luke Kenneth Casson Leighton [this message]
2004-08-02 13:10                             ` Stephen Smalley
2004-08-01 12:11                           ` Luke Kenneth Casson Leighton
2004-08-02 12:38                         ` Stephen Smalley
2004-08-02 12:35                       ` Stephen Smalley
2004-07-29 20:59               ` Valdis.Kletnieks
2004-07-29 22:11                 ` Luke Kenneth Casson Leighton
2004-07-29 14:22         ` Luke Kenneth Casson Leighton
2004-07-29 14:35         ` Luke Kenneth Casson Leighton
2004-07-29 17:04           ` James Morris
2004-07-29 20:56             ` Valdis.Kletnieks
2004-07-29 12:43   ` Stephen Smalley
2004-07-29 13:53     ` Luke Kenneth Casson Leighton
2004-07-29 14:25       ` Stephen Smalley
2004-07-29 12:36 ` Stephen Smalley
2004-07-29 13:57   ` Luke Kenneth Casson Leighton

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=20040801120357.GG7384@lkcl.net \
    --to=lkcl@lkcl.net \
    --cc=russell@coker.com.au \
    --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.