All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@parisplace.org>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: James Morris <jmorris@namei.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Mimi Zohar <zohar@us.ibm.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: fix IMA lockdep circular locking dependency
Date: Wed, 16 May 2012 10:06:41 -0400	[thread overview]
Message-ID: <CACLa4psYWecSy9sRuV2Nf9BPU0xspjJF-ZD63biqv6erUYKyGQ@mail.gmail.com> (raw)
In-Reply-To: <1337176336.3522.5.camel@falcor>

On Wed, May 16, 2012 at 9:52 AM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> On Wed, 2012-05-16 at 09:42 -0400, Eric Paris wrote:
>> On Wed, 2012-05-16 at 21:37 +1000, James Morris wrote:
>> > On Tue, 15 May 2012, Linus Torvalds wrote:
>> >
>> > > Hmm?
>> >
>> > diff --git a/security/capability.c b/security/capability.c
>> > index 5bb21b1c448c..9a19c6a54e12 100644
>> > --- a/security/capability.c
>> > +++ b/security/capability.c
>> > @@ -949,7 +949,6 @@ void __init security_fixup_ops(struct
>> > security_operations *ops)
>> >         set_to_cap_if_null(ops, file_alloc_security);
>> >         set_to_cap_if_null(ops, file_free_security);
>> >         set_to_cap_if_null(ops, file_ioctl);
>> > -       set_to_cap_if_null(ops, file_mmap);
>> >         set_to_cap_if_null(ops, file_mprotect);
>> >         set_to_cap_if_null(ops, file_lock);
>> >         set_to_cap_if_null(ops, file_fcntl);
>> >
>> >
>> > Do we need to add addr_map to the fixup ops?
>>
>> No.  His patch works just fine without it.  If you look he uses:
>>
>> +     if (security_ops->mmap_file) {
>>
>> Which means since we didn't set an explicit .mmap_file, even with no
>> other LSM loaded we would be fine.
>>
>> At the moment I'd rather stick with our usual notation of forcing
>> capabilities to define every option even if all it does it return 0.  If
>> Linus thinks it's a good idea to do
>> if (security_ops->function)
>>       security_ops->funtion(args);
>> In the security server we should do that cleanup separately...
>>
>> -Eric
>
> James was pointing out that security_fixup_ops was not set for
> mmap_addr, not mmap_file(), which should be initialized by
> security_fixup_ops().

But it would be flat wrong to put it there.  True historically we did
things differently, but this patch is right given Linus is doing it a
different way.

Had Linus done what you two are suggesting:
+int security_mmap_addr(unsigned long addr)
+{
+       if (security_ops->mmap_addr) {       <--- This would call cap_mmap_addr
+               int ret = security_ops->mmap_addr(addr);
+               if (ret)
+                       return ret;
+       }
+       return cap_mmap_addr(addr);          <--- This would also call
cap_mmap_addr
+}

See the problem?

Like I said, we can do a full cleanup removing all of the useless
capabilities functions and turning them into an inline branch instead
of unconditional jump and return 0.  We could possibly even move all
of the cap stacking into this layer instead of pushing it into the LSM
layer.  But you shouldn't really do #2 without #1.  (Notice here Linus
is doing both of those things, but only with this one hook)

-Eric

  reply	other threads:[~2012-05-16 14:06 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-14  2:47 [PATCH] vfs: fix IMA lockdep circular locking dependency Mimi Zohar
2012-05-15  0:29 ` James Morris
2012-05-15  0:51   ` Mimi Zohar
2012-05-15 15:14     ` James Morris
2012-05-15 16:06       ` Mimi Zohar
2012-05-15 17:19 ` Linus Torvalds
2012-05-15 18:36   ` Mimi Zohar
2012-05-15 18:41   ` Linus Torvalds
2012-05-15 19:42     ` Eric Paris
2012-05-15 20:07       ` Mimi Zohar
2012-05-15 21:43         ` Linus Torvalds
2012-05-16  0:37           ` Linus Torvalds
2012-05-16  0:42             ` Al Viro
2012-05-16  0:45               ` Linus Torvalds
2012-05-16  1:53                 ` Linus Torvalds
2012-05-16 11:37                   ` James Morris
2012-05-16 11:38                     ` James Morris
2012-05-16 13:27                       ` Mimi Zohar
2012-05-16 13:42                     ` Eric Paris
2012-05-16 13:52                       ` Mimi Zohar
2012-05-16 14:06                         ` Eric Paris [this message]
2012-05-16 15:23                           ` Linus Torvalds
2012-05-16 15:47                           ` Mimi Zohar
2012-05-16 16:09                             ` Linus Torvalds
2012-05-16  2:18                 ` Al Viro
2012-05-23 21:18                   ` Mimi Zohar
2012-05-30  4:34                     ` Al Viro
2012-05-30 16:36                       ` Al Viro
2012-05-30 19:42                         ` Eric Paris
2012-05-30 20:24                           ` Al Viro
2012-05-30 20:28                             ` Linus Torvalds
2012-05-30 20:56                               ` Al Viro
2012-05-30 21:04                                 ` Linus Torvalds
2012-05-30 21:36                                   ` Al Viro
2012-05-30 22:51                                     ` Linus Torvalds
2012-05-31  0:28                                       ` Al Viro
2012-05-31  0:40                                         ` Linus Torvalds
2012-05-31  0:56                                           ` Al Viro
2012-05-31  3:55                                             ` Mimi Zohar
2012-05-31  4:20                                         ` James Morris
2012-05-30 20:33                             ` Mimi Zohar
2012-05-30 20:53                               ` Al Viro
2012-05-16 14:13             ` Eric Paris
2012-05-16 15:13               ` Linus Torvalds

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=CACLa4psYWecSy9sRuV2Nf9BPU0xspjJF-ZD63biqv6erUYKyGQ@mail.gmail.com \
    --to=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.vnet.ibm.com \
    --cc=zohar@us.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 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.