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
19 matches
Mail list logo
