From: Daniel J Walsh <dwalsh@redhat.com>
To: Valdis.Kletnieks@vt.edu
Cc: russell@coker.com.au, Chad Sellers <cdselle@tycho.nsa.gov>,
selinux@tycho.nsa.gov
Subject: Re: [RFC]{Patch 0/5] Polyinstantation
Date: Fri, 13 May 2005 07:15:31 -0400 [thread overview]
Message-ID: <42848C53.4040108@redhat.com> (raw)
In-Reply-To: <200505130553.j4D5rAHI014973@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
>On Fri, 13 May 2005 14:40:39 +1000, Russell Coker said:
>
>
>>Per user /tmp directories break the typical uses of Unix systems. On Unix
>>multi-user systems it's expected that you can copy a file to /tmp and give it
>>mode 0644 to share it with other people.
>>
>>
>
>
>
>Right. Unfortunately, we're swimming upstream against a quarter century
>of common practice that happens to be almost "couldn't design a worse security
>model if we *tried*". A shared /tmp makes sense when everybody's in the same
>security domain, is essentially root anyhow, and file ownerships/permissions
>are there mostly to limit friendly-fire accidents to ones *own* feet, and not
>the co-workers as well. Of course, if you're deploying SELinux, you're no
>longer in Kansas anymore....
>
>Is the polyinstantation addressing:
>
>1) the fact that userB may be able to see/interfere with what userA is doing
>in /tmp, when userA may not desire userB doing so? (If we give userA his own
>instance of /tmp, userB can't interfere).
>
>2) The problem of userA intentionally using /tmp as a zone to pass sensitive
>data to userB, when the site security officer has other ideas? (If we give
>userA his own instance of /tmp, he can't drop a file where userB can get it).
>
>3) Attempting to solve both problems at the same time?
>
>And Russell is correct - although it *does* work when A and B *shouldn't*
>communicate, we *do* need to make *some* provision for the case where users A
>and B are cooperating and allowed to do so by site policy. I suspect that
>"share via /tmp" won't be easily workable, but "share via other file system
>means" will be (we're already looking at a '~/Downloads' type of directory - a
>~/Shared perhaps?)
>
>
>
>
>
None of this stuff will work until we have the ability for the
administrator to change every users view
of the file system. So some kind of shared file system will be
required. I think the idea of the required
shared /tmp is fairly old idea, and not needed much any more, and can
be easily be done using other means.
I figure the ability to use a non shared /tmp should be configurable.
And as Valdis can easily be worked
around by creating another directory for cross machine sharing.
--
--
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.
next prev parent reply other threads:[~2005-05-13 11:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-11 15:28 [RFC]{Patch 0/5] Polyinstantation Chad Sellers
2005-05-11 17:41 ` Casey Schaufler
2005-05-11 18:11 ` Janak Desai
2005-05-11 18:16 ` Chad Sellers
2005-05-11 18:48 ` Timothy R. Chavez
2005-05-11 20:13 ` Daniel J Walsh
2005-05-11 20:40 ` Chad Sellers
2005-05-12 1:30 ` Daniel J Walsh
2005-05-12 11:22 ` Stephen Smalley
2005-05-12 13:22 ` Chad Sellers
2005-05-13 4:40 ` Russell Coker
2005-05-13 5:53 ` Valdis.Kletnieks
2005-05-13 11:15 ` Daniel J Walsh [this message]
2005-05-13 11:30 ` Stephen Smalley
2005-05-19 20:17 ` Chad Sellers
2005-05-12 9:35 ` [selinux] " Magosányi Árpád
-- strict thread matches above, loose matches on Subject: below --
2005-05-11 18:37 Casey Schaufler
2005-05-11 19:02 Casey Schaufler
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=42848C53.4040108@redhat.com \
--to=dwalsh@redhat.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=cdselle@tycho.nsa.gov \
--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.