Pavel Machek <[EMAIL PROTECTED]> wrote on 01/11/2007 09:35:37 AM:
> Hi!
>
> > SLIM implements dynamic process labels, so when a process
> > is demoted, we must be able to revoke write access to some
> > resources to which it has previously valid handles.
> > For example, if a shell reads an untru
On Fri, 12 Jan 2007, Serge E. Hallyn wrote:
> Hmm, would revokefs need to be explicitly stacked on top of the fs,
> or could we just swap out fdt[fd] for the revokefs file, and have
> the revokefs file's private data point to the original inode, with
> it's write function returning an error, and re
Quoting Pekka Enberg ([EMAIL PROTECTED]):
> On 1/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >Now, what slim needs isn't "revoke all files for this inode",
> >but "revoke this task's write access to this fd". So two functions
> >which could be useful are
> >
> >int fd_revoke_write(
Quoting Pekka Enberg ([EMAIL PROTECTED]):
> On 1/11/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >Right, but is returning -EINVAL to userspace on munmap a problem?
>
> Yes, because an application has no way of reusing the revoked mapping
> range. The current patch should get this right, though
Hi!
> SLIM implements dynamic process labels, so when a process
> is demoted, we must be able to revoke write access to some
> resources to which it has previously valid handles.
> For example, if a shell reads an untrusted file, the
> shell is demoted, and write access to more trusted files
> rev
On 1/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Now, what slim needs isn't "revoke all files for this inode",
but "revoke this task's write access to this fd". So two functions
which could be useful are
int fd_revoke_write(struct task_struct *tsk, int fd)
int fd_revoke_wr
On 1/11/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Right, but is returning -EINVAL to userspace on munmap a problem?
Yes, because an application has no way of reusing the revoked mapping
range. The current patch should get this right, though.
On 1/11/07, Serge E. Hallyn <[EMAIL PROTECTED]>
Quoting Pekka Enberg ([EMAIL PROTECTED]):
> On 1/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >But since it looks like you just munmap the region now, shouldn't a
> >subsequent munmap by the app just return -EINVAL? that seems appropriate
> >to me.
>
> Applications don't know about revoke
On 1/10/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
But since it looks like you just munmap the region now, shouldn't a
subsequent munmap by the app just return -EINVAL? that seems appropriate
to me.
Applications don't know about revoke and neither should they.
Therefore close(2) and munmap
Quoting Pekka J Enberg ([EMAIL PROTECTED]):
> On Tue, 9 Jan 2007, Serge E. Hallyn wrote:
> > Whatever happened with Pekka's revoke submissions? Did you lose
> > interest after
> > http://www.kernel.org/pub/linux/kernel/people/penberg/patches/revoke/2.6.19-rc1/revoke-2.6.19-rc1,
> > or was it decid
On Tue, 9 Jan 2007, Serge E. Hallyn wrote:
> Whatever happened with Pekka's revoke submissions? Did you lose
> interest after
> http://www.kernel.org/pub/linux/kernel/people/penberg/patches/revoke/2.6.19-rc1/revoke-2.6.19-rc1,
> or was it decided that the approach was unworkable?
Lack of time. Al
Quoting Christoph Hellwig ([EMAIL PROTECTED]):
> On Mon, Jan 08, 2007 at 07:07:25PM -0800, Arjan van de Ven wrote:
> >
> > > Starting with the fdtable, would it help if we move the
> > > fdtable tweaking out of slim itself and into helpers? Or
> > > can you recommend another way to implement this
[EMAIL PROTECTED] wrote on 01/09/2007 02:27:19 PM:
>Which, unfortunately, creates incredibly brittle code when some attacker
>reads the SLIM source code and finds a way to force the non-simple case
>you ignore.
>
>This is an area where you really need to do it *right*, or not at all.
For the non
Arjan van de Ven <[EMAIL PROTECTED]> wrote on 01/08/2007 10:07:25 PM:
> Hi,
>
>maybe this is a silly question, but do you revoke not only the current
>fd entries, but also the ones that are pending in UNIX domain sockets
>and that are already being sent to the process? If not.. then you might
>as
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Mon, Jan 08, 2007 at 07:07:25PM -0800, Arjan van de Ven wrote:
> > maybe this is a silly question, but do you revoke not only the current
> > fd entries, but also the ones that are pending in UNIX domain sockets
> > and that are already being sent
On Mon, 08 Jan 2007 17:38:25 EST, Mimi Zohar said:
> revoked. Based on previous comments on lkml, we understand
> that this is not really possible in general, so SLIM only
> attempts to revoke access in certain simple cases.
Which, unfortunately, creates incredibly brittle code when some attacker
On Mon, Jan 08, 2007 at 07:07:25PM -0800, Arjan van de Ven wrote:
>
> > Starting with the fdtable, would it help if we move the
> > fdtable tweaking out of slim itself and into helpers? Or
> > can you recommend another way to implement this functionality.
>
> Hi,
>
> maybe this is a silly ques
> Starting with the fdtable, would it help if we move the
> fdtable tweaking out of slim itself and into helpers? Or
> can you recommend another way to implement this functionality.
Hi,
maybe this is a silly question, but do you revoke not only the current
fd entries, but also the ones that ar
SLIM implements dynamic process labels, so when a process
is demoted, we must be able to revoke write access to some
resources to which it has previously valid handles.
For example, if a shell reads an untrusted file, the
shell is demoted, and write access to more trusted files
revoked. Based on pr
Folks, WTF were you smoking when writing the slim code? Calling mprotect
from random code to rewoke write permissions on process is not okay. As
is poking into the dile desriptor tables. As is ding permission checks
based on d_path output.
Andrew, could you please just drop slim? The code isn'
20 matches
Mail list logo
