James Morris wrote:
> On Thu, 21 Jun 2007, Chris Mason wrote:
>>> The incomplete mediation flows from the design, since the pathname-based
>>> mediation doesn't generalize to cover all objects unlike label- or
>>> attribute-based mediation. And the "use the natural abstraction for
>>> each objec
On Thu, 21 Jun 2007, Joshua Brindle wrote:
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Joshua Brindle wrote:
> Lars Marowsky-Bree wrote:
> > On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > Um, no. It might not be able to directly open files vi
[EMAIL PROTECTED] wrote:
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Um, no. It might not be able to directly open files via that
path, but
> showing that it can never read or write your mail
On Thu, 21 Jun 2007, Chris Mason wrote:
> > The incomplete mediation flows from the design, since the pathname-based
> > mediation doesn't generalize to cover all objects unlike label- or
> > attribute-based mediation. And the "use the natural abstraction for
> > each object type" approach likewi
On Thu, Jun 21, 2007 at 04:59:54PM -0400, Stephen Smalley wrote:
> On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> >
> > > > A veto is not a technical argument. All technical arguments (except for
> > > > "path name
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Um, no. It might not be able to directly open files via that path, but
> showing that it can never read or write your mail is a rather different
> m
On 2007-06-21T20:16:25, Joshua Brindle <[EMAIL PROTECTED]> wrote:
> not. One need only look at the wonderful marketing literature for AA to
> see what you are telling people it can do, and your above statement
> isn't consistent with that, sorry.
I'm sorry. I don't work in marketing.
--
Team
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
Um, no. It might not be able to directly open files via that path, but
showing that it can never read or write your mail is a rather different
matter.
Yes. Your use case is different than mi
On Thu, Jun 21, 2007 at 10:21:07PM +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T22:07:40, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> >
> > Plus IIRC we have something like "AA has to allocate path-sized
> > buffers along every syscall".
>
> That is an implementation bug though. I'm sure we
On 2007-06-21T16:59:54, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Or can access the data under a different path to which their profile
> does give them access, whether in its final destination or in some
> temporary file processed along the way.
Well, yes. That is intentional.
Your point is?
On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
>
> > > A veto is not a technical argument. All technical arguments (except for
> > > "path name is ugly, yuk yuk!") have been addressed, have they not?
> > AppArmor doesn
On 2007-06-21T22:07:40, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > AA is supposed to allow valid access patterns, so for non-buggy apps +
> > policies, the rename will be fine and does not change the (observed)
> > permissions.
> That still breaks POSIX, right? Hopefully it will not break any app
Hi!
> > I believe AA breaks POSIX, already. rename() is not expected to change
> > permissions on target, nor is link link. And yes, both of these make
> > AA insecure.
>
> AA is supposed to allow valid access patterns, so for non-buggy apps +
> policies, the rename will be fine and does not chan
On 2007-06-21T15:42:28, James Morris <[EMAIL PROTECTED]> wrote:
> > A veto is not a technical argument. All technical arguments (except for
> > "path name is ugly, yuk yuk!") have been addressed, have they not?
> AppArmor doesn't actually provide confinement, because it only operates on
> filesys
Hi!
> >>The code has improved, and continues to improve, to meet all the coding
> >>style feedback except the bits which are essential to AA's function
> >
> >Which are exactly the bits Christoph Hellwig and Al Viro
> >vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> >. I b
On Thu, 21 Jun 2007, Lars Marowsky-Bree wrote:
> A veto is not a technical argument. All technical arguments (except for
> "path name is ugly, yuk yuk!") have been addressed, have they not?
AppArmor doesn't actually provide confinement, because it only operates on
filesystem objects.
What you d
On 2007-06-21T12:30:08, [EMAIL PROTECTED] wrote:
> well, if you _really_ want people who are interested in this to do weekly
> "why isn't it merged yet you $%#$%# developers" threads that can be
> arranged.
>
> the people who want this have been trying to be patient and let the system
> work.
On Thu, 21 Jun 2007, Pavel Machek wrote:
If that is the only way to implement AA on top of SELinux - and so far,
noone has made a better suggestion - I'm convinced that AA has technical
merit: it does something the on-disk label based approach cannot handle,
and for which there is demand.
What
On 2007-06-21T20:33:11, Pavel Machek <[EMAIL PROTECTED]> wrote:
> inconvenient, yes, insecure, no.
Well, only if you use the most restrictive permissions. And then you'll
suddenly hit failure cases which you didn't expect to, which can
possibly cause another exploit to become visible.
> I believ
Hi!
> I've caught up on this thread with growing disbelief while reading the
> mails, so much that I've found it hard to decide where to reply to.
>
> So people are claiming that AA is ugly, because it introduces pathnames
> and possibly a regex interpreter. Ok, taste differs. We've got many
> di
Hi!
> >> It's really not worth getting bothered by. Truth is, big
> >> giant
> >> pathnames break lots of stuff already, both kernel and
> >> userspace.
> >
> >> Just look in /proc for some nice juicy kernel breakage:
> >> cwd, exe, fd/*, maps, mounts, mountstats, root, smaps
> >
> >Well, but we s
On Thu 2007-06-21 18:01:05, Andreas Gruenbacher wrote:
> On Saturday 16 June 2007 01:49, Greg KH wrote:
> > But for those types of models that do not map well to internal kernel
> > structures, perhaps they should be modeled on top of a security system that
> > does handle the internal kernel repre
I've caught up on this thread with growing disbelief while reading the
mails, so much that I've found it hard to decide where to reply to.
So people are claiming that AA is ugly, because it introduces pathnames
and possibly a regex interpreter. Ok, taste differs. We've got many
different flavours
On Saturday 16 June 2007 01:49, Greg KH wrote:
> But for those types of models that do not map well to internal kernel
> structures, perhaps they should be modeled on top of a security system that
> does handle the internal kernel representation of things in the way the
> kernel works.
How exactly
Quoting Chris Wright ([EMAIL PROTECTED]):
> [folks, this is getting much too long-winded to stay a private thread]
>
> * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> > Quoting Chris Wright ([EMAIL PROTECTED]):
> > > * Andrew Morgan ([EMAIL PROTECTED]) wrote:
> > > > I share Casey's view that what'
On Monday 18 June 2007 15:33, Stephen Smalley wrote:
> On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> > There are two things:
> >
> > 1) relabeling (non-tranquility) is very problematic in general because
> > revocation is hard (and non-solved in Linux). So you would have to
> > address
26 matches
Mail list logo
