From: John Johansen <jjohansen@suse.de>
To: david@lang.hm
Cc: Andi Kleen <andi@firstfloor.org>,
Crispin Cowan <crispin@crispincowan.com>,
Arjan van de Ven <arjan@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
LSM ML <linux-security-module@vger.kernel.org>,
apparmor-dev <apparmor-dev@forge.novell.com>
Subject: Re: AppArmor Security Goal
Date: Sat, 10 Nov 2007 19:36:34 -0800 [thread overview]
Message-ID: <20071111033634.GB19216@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0711101325240.4780@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Sat, Nov 10, 2007 at 01:28:25PM -0800, david@lang.hm wrote:
> On Sat, 10 Nov 2007, Andi Kleen wrote:
>
>> Crispin Cowan <crispin@crispincowan.com> writes:
>>
>> The document should be a good base for a merge.
>>
>>> * A confined process can operate on a file descriptor passed to it
>>> by an unconfined process, even if it manipulates a file not in the
>>> confined process's profile. To block this attack, confine the
>>> process that passed the file descriptor.
>>
>> That is the only thing that tripped me up a bit while reading the
>> document.
>> Can you expand a bit on the reasons why the fd is not rechecked in
>> the context of the target process? Best do it in a new version of the
>> document.
>
> from prior discussions I understand that the problem is that it's not easy
> (or nessasarily possible) to figure out the path to the fd, so what do you
> check?
>
> if the file has been removed there _is_ no path to the fd.
>
> with hard links there could be many paths to the fd, the only way to find
> them would be to search the entire filesystem.
>
> as a result App Armor has decided not to try and address this, but is
> documenting it as a limitation.
>
Actually no. The unconfined fd being passed in is explicitly different
than and fd being passed between two confined processes. In the
unconfined parent passing an fd into a confined child the fd isn't
reevaluated. In the case of confined parent to confined child the
the struct file is reevaluated.
As to the implementation issue of revalidation. The path name to file can
be found as struct file stores both the vfsmnt and dentry. With that said
there are a couple cases where the pathname can't be found.
- the file has been deleted
- the path has become disconnected.
In short under file revalidation deleted file are given a pass and
disconnected files fail.
For a more in depth explanation look at
http://forgeftp.novell.com//apparmor/LKML_Submission-Oct-07/techdoc.pdf
regards
john
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
next prev parent reply other threads:[~2007-11-11 3:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-08 21:33 AppArmor Security Goal Crispin Cowan
2007-11-10 21:04 ` Andi Kleen
2007-11-10 21:24 ` Crispin Cowan
2007-11-11 3:23 ` John Johansen
2007-11-10 21:28 ` david
2007-11-11 3:36 ` John Johansen [this message]
2007-11-10 22:04 ` Dr. David Alan Gilbert
2007-11-10 22:11 ` Crispin Cowan
2007-11-10 22:24 ` Dr. David Alan Gilbert
2007-11-10 22:41 ` Crispin Cowan
2007-11-10 22:57 ` Alan Cox
2007-11-10 23:14 ` Crispin Cowan
2007-11-10 23:54 ` Alan Cox
2007-11-10 23:25 ` Dr. David Alan Gilbert
2007-11-10 23:52 ` david
2007-11-10 23:47 ` Dr. David Alan Gilbert
2007-11-10 23:56 ` Alan Cox
2007-11-11 1:27 ` david
2007-11-11 3:59 ` John Johansen
2007-11-12 23:58 ` Crispin Cowan
2007-11-11 4:17 ` John Johansen
2007-11-11 4:50 ` david
2007-11-13 0:13 ` Crispin Cowan
2007-11-11 7:02 ` Rogelio M. Serrano Jr.
2007-11-12 23:50 ` Crispin Cowan
2007-11-13 1:20 ` John Johansen
2007-11-11 2:17 ` Casey Schaufler
2007-11-11 3:55 ` John Johansen
2007-11-13 0:10 ` Joshua Brindle
2007-11-13 4:58 ` Casey Schaufler
-- strict thread matches above, loose matches on Subject: below --
2007-11-11 8:16 Rob Meijer
[not found] <9nngC-6iQ-25@gated-at.bofh.it>
[not found] ` <9o6Qq-2Hk-17@gated-at.bofh.it>
[not found] ` <9o6Qq-2Hk-15@gated-at.bofh.it>
[not found] ` <9o706-2Xe-17@gated-at.bofh.it>
[not found] ` <9o7jp-3lE-5@gated-at.bofh.it>
[not found] ` <9o7Wg-4sT-15@gated-at.bofh.it>
[not found] ` <9of7j-7ej-7@gated-at.bofh.it>
2007-11-12 18:43 ` Bodo Eggert
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=20071111033634.GB19216@suse.de \
--to=jjohansen@suse.de \
--cc=andi@firstfloor.org \
--cc=apparmor-dev@forge.novell.com \
--cc=arjan@infradead.org \
--cc=crispin@crispincowan.com \
--cc=david@lang.hm \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
/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