From: Casey Schaufler <casey@schaufler-ca.com>
To: Roberto Sassu <roberto.sassu@polito.it>
Cc: John Johansen <john.johansen@canonical.com>,
Tyler Hicks <tyhicks@linux.vnet.ibm.com>,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
dhowells@redhat.com, jmorris@namei.org, zohar@linux.vnet.ibm.com,
safford@watson.ibm.com, kirkland@canonical.com,
ecryptfs-devel@lists.launchpad.net, eparis@redhat.com,
sds@tycho.nsa.gov, selinux@tycho.nsa.gov,
viro@zeniv.linux.org.uk, apparmor@lists.ubuntu.com,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [RFC][PATCH 0/7] File descriptor labeling
Date: Wed, 04 May 2011 10:34:51 -0700 [thread overview]
Message-ID: <4DC18E3B.2000104@schaufler-ca.com> (raw)
In-Reply-To: <201105041047.57161.roberto.sassu@polito.it>
On 5/4/2011 1:47 AM, Roberto Sassu wrote:
> On Wednesday, May 04, 2011 01:58:00 AM John Johansen wrote:
>> ....
>> I have to agree with Casey, Generally looping back through the vfs should
>> be using the user's credentials. This doesn't even stop you opening the
>> lower file with a different set of permissions (eg. rw while the upper
>> is opened with r).
> Hi Casey and John
>
> my patch set does not modify this behavior: VFS calls on upper inodes
> made by user processes and VFS calls (read/write) made by eCryptfs
> on lower inodes still use the user's credentials.
>
> In addition, SELinux provide a model for file descriptors. They may be
> opened by another subject (which provided its own credentials) and
> other processes need the 'use' permission for those file descriptors
> other than permissions for related inodes.
>
> This means that, even if eCryptfs opens lower inodes with its own
> credentials, user processes still need permissions to read/write both
> upper and lower inodes.
>
> One benefit of allowing eCryptfs to provide its own credentials is that
> user processes must have granted only strictly required permissions.
>
> Roberto Sassu
My point is that you should be able to achieve all of what you
say you want to do without introducing the LSM changes you are
proposing.
next prev parent reply other threads:[~2011-05-04 17:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 9:39 [RFC][PATCH 0/7] File descriptor labeling Roberto Sassu
2011-04-29 15:46 ` Casey Schaufler
2011-05-02 8:53 ` Roberto Sassu
2011-05-03 22:58 ` Casey Schaufler
2011-05-03 23:58 ` John Johansen
2011-05-04 8:47 ` Roberto Sassu
2011-05-04 17:34 ` Casey Schaufler [this message]
2011-05-04 9:19 ` Roberto Sassu
2011-05-04 17:42 ` Casey Schaufler
-- strict thread matches above, loose matches on Subject: below --
2011-04-27 12:34 Roberto Sassu
2011-04-27 15:52 ` Casey Schaufler
2011-04-27 20:19 ` Casey Schaufler
2011-04-27 23:27 ` Tyler Hicks
2011-04-27 23:57 ` Casey Schaufler
2011-04-28 0:06 ` Tyler Hicks
2011-04-28 12:35 ` Roberto Sassu
2011-04-28 17:37 ` Casey Schaufler
2011-04-28 17:56 ` Eric Paris
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=4DC18E3B.2000104@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=apparmor@lists.ubuntu.com \
--cc=dhowells@redhat.com \
--cc=ecryptfs-devel@lists.launchpad.net \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=kirkland@canonical.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=roberto.sassu@polito.it \
--cc=safford@watson.ibm.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=tyhicks@linux.vnet.ibm.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zohar@linux.vnet.ibm.com \
/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