lkml.org 
[lkml]   [2014]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Kernel panic at Ubuntu: IMA + Apparmor
    Dmitry Kasatkin <dmitry.kasatkin@gmail.com> writes:

    > On 25 April 2014 23:01, Oleg Nesterov <oleg@redhat.com> wrote:
    >> On 04/25, Eric W. Biederman wrote:
    >>>
    >>> Oleg Nesterov <oleg@redhat.com> writes:
    >>>
    >>> > Well. I _think_ that __fput() and ima_file_free() in particular should not
    >>> > depend on current and/or current->nsproxy. If nothing else, fput() can be
    >>> > called by the unrelated task which looks into /proc/pid/.
    >>> >
    >>> > But again, task_work_add() has more and more users, and it seems that even
    >>> > __fput() paths can do "everything", so perhaps it would be safer to allow
    >>> > to use ->nsproxy in task_work_run.
    >>>
    >>> Like I said, give me a clear motivating case.
    >>
    >> I agree, we need a reason. Currently I do not see one.
    >>
    >>> Right now not allowing
    >>> nsproxy is turning up bugs in __fput. Which seems like a good thing.
    >>
    >> This is what I certainly agree with ;)
    >>
    >
    > Hi,
    >
    > IMA uses kernel_read API which does not know anything about caller.
    > And of course security frameworks are at guard as usual.
    >
    > Exactly after reading first Eric's respons, I thought why to scratch
    > the head when task work queues are indeed designed for tasks...

    __fput has no guarantee of running in the task that close the file
    descriptor. If your code depends on that your code is broken.

    > And if you to dig for the history, IMA-appraisal was stuck due to
    > lockdep reporting even though it was on non-everlaping cases.
    > IIRC files vs. directories...
    >
    > After that IIRC Al Viro discussed about delayed fput and IIRC Oleg
    > (sorry if I am wrong) introduced task work queues.
    >
    > So IMA-appraisal was able to be upstreamed... That was ~3.4 time frame, IIRC
    >
    > Name space also dated around ~3.4??
    > Apparmor namespace change was also around that time.
    >
    > 3.10 introduces this name space order change and broke IMA-appraisal.

    IMA-appraisal is fundamentally broken because I can take a mandatory
    file lock and prevent IMA-apprasial.

    Using kernel_read is what allows this.

    > Isn't it a clear motivating case???

    kernel_read is not appropriate for IMA use. The rest of this is just
    the messenger.

    IMA needs to use a cousin of kernel_read that operates at a lower level
    than vfs_read. A function that all of the permission checks and the
    fsnotify work.

    I am sorry to be the bearer of bad news. But kernel_read is totally
    inappropriate for IMA.

    Eric



    \
     
     \ /
      Last update: 2014-04-25 23:01    [W:8.684 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site