Hi!
> >What you do with AppArmor, instead of addressing the problem, is just
> >redefine the environment along the lines of "set your house into a rock
> >wall so there is only one path to it".
>
> Harrumph. Those analogies sound good but aren't a very good guide.
>
> Let's take a concrete ex
Hi!
One more...
> 2. This is argument #1 in a different guise and I find it about as weak.
> Pathname-based access control has strengths and weaknesses. I think
> users and Linux distributions are in a better position to evaluate those
> tradeoffs than L-K. Competition is good.
It took you qui
Hi!
> I've heard four arguments against merging AA.
>
> Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA.
> Or: SELinux can do everything that AA can.)
>
> Argument 2. Object labeling (or: information flow control) is more secure
> than pathname-based access control.
>
> A
Chris Wright wrote:
> * Chris Mason ([EMAIL PROTECTED]) wrote:
>> I'm sure people there will have a different versions of events. The
>> one part that was discussed was if pathname based security was
>> useful, and a number of the people in the room (outside of
>> novell) said it was. Now, it
On 2007-06-25T17:14:11, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Actually, I surprised Lars a lot by telling him ln /etc/shadow /tmp/
> allows any user to make AA ineffective on large part of systems -- in
> internal discussion. (It is not actually a _bug_, but it is certainly
> unexpected).
Pav
On Mon, 25 Jun 2007, Pavel Machek wrote:
Hi!
We've been over the "AA is different" discussion in threads about a
billion times, and at the last kernel summit. I think Lars and others
have done a pretty good job of describing the problems they are trying
to solve, can we please move on to disc
Hi!
> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit. I think Lars and others
> have done a pretty good job of describing the problems they are trying
> to solve, can we please move on to discussing technical issues around
> that
On Sun, 24 Jun 2007, David Wagner wrote:
Argument 3. AA isn't complete until it mediates network and IPC.
Let me comment on these one-by-one.
3. This one I agree with. If you want to sandbox network daemons that
you're concerned might get hacked, then you really want your sandbox to
mediate e
James Morris wrote:
>A. Pathname labeling - applying access control to pathnames to objects,
>rather than labeling the objects themselves.
>
>Think of this as, say, securing your house by putting a gate in the street
>in front of the house, regardless of how many other possible paths there
>are
James Morris wrote:
>The point is that the pathname model does not generalize, and that
>AppArmor's inability to provide adequate coverage of the system is a
>design issue arising from this.
I don't see it. I don't see why you call this a design issue. Isn't
this just a case where they haven'
I've heard four arguments against merging AA.
Argument 1. SELinux does it better than AA. (Or: SELinux dominates AA.
Or: SELinux can do everything that AA can.)
Argument 2. Object labeling (or: information flow control) is more secure
than pathname-based access control.
Argument 3. AA isn't com
Stephen Smalley wrote:
>On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
>> No the "incomplete" mediation does not flow from the design. We have
>> deliberately focused on doing the necessary modifications for pathname
>> based mediation. The IPC and network mediation are a wip.
>
>The fa
Stephen Smalley wrote:
>That would certainly help, although one might quibble with the use of
>the word "confinement" at all wrt AppArmor (it has a long-established
>technical meaning that implies information flow control, and that goes
>beyond even complete mediation - it requires global and pers
Hi!
> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
>
> while(1)
> AA) we think we're making users happy with pathname security
> SELINUX) pathname security sucks
(Hopefully I'll not be fired for this. :-)
Yes, we _are
Stephen Smalley wrote:
>On Thu, 2007-06-21 at 21:54 +0200, Lars Marowsky-Bree wrote:
>> And now, yes, I know AA doesn't mediate IPC or networking (yet), but
>> that's a missing feature, not broken by design.
>
>The incomplete mediation flows from the design, since the pathname-based
>mediation doe
This thread is amazing. With so many smart people's precious time,
What are the results?
What are the issues anyway?
Is anyone happy? (I'm not and I assume Chris is not)
Yes, "waste of time" is taking place here, but
it's not for "pathname-based MAC" but for "wrongly posted messages",
I believe
This thread is amazing. With so many smart people's precious time,
What are the results?
What are the issues anyway?
Is anyone happy? (I'm not and I assume Chris is not)
Yes, "waste of time" is taking place here, but
it's not for "pathname-based MAC" but for "wrongly posted messages",
I believe.
* Chris Mason ([EMAIL PROTECTED]) wrote:
> I'm sure people there will have a different versions of events. The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of
> novell) said it was. Now, it could be that nobody wanted
On Fri, 22 Jun 2007, Stephen Smalley wrote:
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
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:
On Fri, 22 Jun 2007, James Morris wrote:
On Fri, 22 Jun 2007, Chris Mason wrote:
But, this is a completely different discussion than if AA is
solving problems in the wild for its intended audience, or if the code
is somehow flawed and breaking other parts of the kernel.
Is its intended audie
On Fri, Jun 22, 2007 at 10:23:03AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
>
> > But, this is a completely different discussion than if AA is
> > solving problems in the wild for its intended audience, or if the code
> > is somehow flawed and breaking other parts of th
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Mandatory access control as historically understood has always meant
> system-wide.
Chapter and verse: TCSEC 3.1.1.4 Mandatory Access Control
"The TCB shall enforce a mandatory access control policy over
all subjects and storage objects und
On Fri, 2007-06-22 at 09:22 -0400, Stephen Smalley wrote:
> On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> > On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > > Sorry, do you mean the "server" as in the "server system" or as in the
> > > "server daemon"? For th
On Fri, 22 Jun 2007, Chris Mason wrote:
> But, this is a completely different discussion than if AA is
> solving problems in the wild for its intended audience, or if the code
> is somehow flawed and breaking other parts of the kernel.
Is its intended audience aware of its limitiations? Lars has
On Fri, Jun 22, 2007 at 09:48:12AM -0400, James Morris wrote:
> On Fri, 22 Jun 2007, Chris Mason wrote:
>
> > > The validity or otherwise of pathname access control is not being
> > > discussed here.
> > >
> > > The point is that the pathname model does not generalize, and that
> > > AppArmor's
On Fri, 22 Jun 2007, Chris Mason wrote:
> > The validity or otherwise of pathname access control is not being
> > discussed here.
> >
> > The point is that the pathname model does not generalize, and that
> > AppArmor's inability to provide adequate coverage of the system is a
> > design issue
On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > Sorry, do you mean the "server" as in the "server system" or as in the
> > "server daemon"? For the former, I'd agree - we would want SELinux
> > policy applied on
On 2007-06-22T08:41:51, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> The issue arises even for a collection of collaborating confined
> processes with different profiles, and the collaboration may be
> intentional or unintentional (in the latter case, one of the confined
> processes may be taking
On Fri, 2007-06-22 at 14:42 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > > No the "incomplete" mediation does not flow from the design. We have
> > > deliberately focused on doing the necessary modifications for pathname
> > > based m
On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote:
> On 2007-06-22T07:19:39, 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
> > > > tempor
On 2007-06-22T07:53:47, Stephen Smalley <[EMAIL PROTECTED]> wrote:
> > No the "incomplete" mediation does not flow from the design. We have
> > deliberately focused on doing the necessary modifications for pathname
> > based mediation. The IPC and network mediation are a wip.
> The fact that you
On Thu, Jun 21, 2007 at 09:06:40PM -0400, 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 th
On Thu, 2007-06-21 at 22:17 -0600, Crispin Cowan wrote:
> 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 m
On Fri, 2007-06-22 at 01:06 -0700, John Johansen wrote:
> 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:
> > >
> >
> > > And now, yes, I know AA
On Fri, 2007-06-22 at 21:34 +1000, Neil Brown wrote:
> On Friday June 22, [EMAIL PROTECTED] wrote:
> > >
> > > Yes. Your use case is different than mine.
> >
> > My use case is being able to protect data reliably. Yours?
>
> Saying "protect data" is nearly meaningless without a threat model.
>
On 2007-06-22T07:19:39, 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.
>
On Friday June 22, [EMAIL PROTECTED] wrote:
> >
> > Yes. Your use case is different than mine.
>
> My use case is being able to protect data reliably. Yours?
Saying "protect data" is nearly meaningless without a threat model.
I bet you don't try to protect data from a direct nuclear hit, or a
c
On Thu, 2007-06-21 at 23:17 +0200, Lars Marowsky-Bree wrote:
> 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 pro
On 2007-06-21T23:45:36, Joshua Brindle <[EMAIL PROTECTED]> wrote:
> >remember, the policies define a white-list
>
> Except for unconfined processes.
The argument that AA doesn't mediate what it is not configured to
mediate is correct, yes, but I don't think that's a valid _design_ issue
with AA.
On Saturday 16 June 2007 02:20, Pavel Machek wrote:
> Ok, so mv gets slower for big trees... and open() gets faster for deep
> trees. Previously, open in current directory was one atomic read of
> directory entry, now it has to read directory, and its parent, and its
> parent parent, and its...
>
>
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:
> >
>
> > And now, yes, I know AA doesn't mediate IPC or networking (yet), but
> > that's a missing f
On Thu, Jun 21, 2007 at 09:06:40PM -0400, 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 th
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
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
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
Hi!
> > In a smaller scale example, I want to share some files with a friend. I
> > can't be bothered to set up a proper access control system, so I just mv
> > the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> > going away in 10 minutes" and then move it out again. Yes, you
Greg KH wrote:
> On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
>
>> Then there's all the other problems, such as file systems that don't
>> support extended attributes, particularly NFS3. Yes, NFS3 is vulnerable
>> to network attack, but that is not the threat AA is addressing.
On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler
On Fri, 2007-06-15 at 13:43 -0700, Casey Schaufler wrote:
> --- Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2007-06-15 at 11:01 -0700, Casey Schaufler wrote:
> > > --- Greg KH <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > > A daemon using inotify can "instantly"[1] detect this and la
Casey Schaufler wrote:
--- James Morris <[EMAIL PROTECTED]> wrote:
On Fri, 15 Jun 2007, Casey Schaufler wrote:
--- James Morris <[EMAIL PROTECTED]> wrote:
On my system, it takes about 1.2 seconds to label a fully checked out
kernel source tree with ~23,000 files in this manne
--- James Morris <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jun 2007, Casey Schaufler wrote:
>
> >
> > --- James Morris <[EMAIL PROTECTED]> wrote:
> >
> > > On my system, it takes about 1.2 seconds to label a fully checked out
> > > kernel source tree with ~23,000 files in this manner
> >
> > T
On Sat, Jun 16, 2007 at 01:09:06AM -0700, [EMAIL PROTECTED] wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> >>> Usually you don't do that by doing a 'mv' otherwise you are almost
> >>> guaranteed stale and mixed up content for some period of time, not to
> >>> mention the issues surrounding path
On Sun, Jun 17, 2007 at 12:44:08AM +0900, Tetsuo Handa wrote:
> Greg KH wrote:
> > A daemon using inotify can "instantly"[1] detect this and label the file
> > properly if it shows up.
>
> > Same daemon can do the re-label.
>
> Can the daemon using inotify access to all pathnames in all process's
Greg KH wrote:
> A daemon using inotify can "instantly"[1] detect this and label the file
> properly if it shows up.
> Same daemon can do the re-label.
Can the daemon using inotify access to all pathnames in all process's
namespaces?
Are the namespace the daemon has and the namespace of pathname
On Fri, 15 Jun 2007, Greg KH wrote:
Usually you don't do that by doing a 'mv' otherwise you are almost
guaranteed stale and mixed up content for some period of time, not to
mention the issues surrounding paths that might be messed up.
on the contrary, useing 'mv' is by far the cleanest way to
Hi!
> > The question is: why not just extend SELinux to include AA functionality
> > rather than doing a whole new subsystem.
>
> Because, as hard as it seems for some people to believe,
> not everyone wants Type Enforcement. SELinux is a fine
> implementation of type enforcement, but if you don'
On Fri, Jun 15, 2007 at 09:21:57PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > Oh great, then things like source code control systems would have no
> > problems with new files being created under them, or renaming whole
> > trees.
>
> It depends -- I think we may be tal
On Fri, 15 Jun 2007, Casey Schaufler wrote:
>
> --- James Morris <[EMAIL PROTECTED]> wrote:
>
> > On my system, it takes about 1.2 seconds to label a fully checked out
> > kernel source tree with ~23,000 files in this manner
>
> That's an eternity for that many files to be improperly labeled.
--- James Morris <[EMAIL PROTECTED]> wrote:
> On my system, it takes about 1.2 seconds to label a fully checked out
> kernel source tree with ~23,000 files in this manner
That's an eternity for that many files to be improperly labeled.
If, and the "if" didn't originate with me, your policy is
d
On Fri, 15 Jun 2007, Seth Arnold wrote:
> The time for restorecon is probably best imagined as a kind of 'du' that
> also updates extended attributes as it does its work. It'd be very
> difficult to improve on this.
restorecon can most definitely be improved.
- James
--
James Morris
<[EMAIL P
On Fri, 15 Jun 2007, Seth Arnold wrote:
> > How does inotify not work here? You are notified that the tree is
> > moved, your daemon goes through and relabels things as needed. In the
> > meantime, before the re-label happens, you might have the wrong label on
> > things, but "somehow" SELinux a
On Fri, 15 Jun 2007, [EMAIL PROTECTED] wrote:
> on the contrary, useing 'mv' is by far the cleanest way to do this.
>
> mv htdocs htdocs.old;mv htdocs.new htdocs
>
> this makes two atomic changes to the filesystem, but can generate thousands to
> millions of permission changes as a result.
OTOH
On Fri, 15 Jun 2007, Greg KH wrote:
> Oh great, then things like source code control systems would have no
> problems with new files being created under them, or renaming whole
> trees.
It depends -- I think we may be talking about different things.
If you're using inotify to watch for new files
Crispin Cowan wrote:
> In a smaller scale example, I want to share some files with a friend. I
> can't be bothered to set up a proper access control system, so I just mv
> the files to ~crispin/public_html/lookitme and in IRC say "get it now,
> going away in 10 minutes" and then move it out again.
On Fri, Jun 15, 2007 at 05:01:25PM -0700, [EMAIL PROTECTED] wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> >> Greg KH wrote:
> >>> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Only case where attacker _ca
On Fri, Jun 15, 2007 at 05:18:10PM -0700, Seth Arnold wrote:
> On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > > We have built a label-based AA prototype. It fails because there is no
> > > reasonable way to address the tree renaming problem.
> >
> > How does inotify not work here? Y
Hi!
> >>Under the restorecon proposal, the web site would be horribly broken
> >>until restorecon finishes, as various random pages are or are not
> >>accessible to Apache.
> >
> >Usually you don't do that by doing a 'mv' otherwise you are almost
> >guaranteed stale and mixed up content for some p
On Fri, Jun 15, 2007 at 04:49:25PM -0700, Greg KH wrote:
> > We have built a label-based AA prototype. It fails because there is no
> > reasonable way to address the tree renaming problem.
>
> How does inotify not work here? You are notified that the tree is
> moved, your daemon goes through and
On Sat, Jun 16, 2007 at 01:39:14AM +0200, Pavel Machek wrote:
> > Pavel, please focus on the current AppArmor implementation. You're
> > remembering a flaw with a previous version of AppArmor. The pathnames
> > constructed with the current version of AppArmor are consistent and
> > correct.
>
> Ok
Hi!
> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem alread
On Fri, 15 Jun 2007, Greg KH wrote:
On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
Greg KH wrote:
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
Only case where attacker _can't_ be keeping file descriptors is newly
created files in recently moved tree. But as yo
On Fri, Jun 15, 2007 at 04:30:44PM -0700, Crispin Cowan wrote:
> Greg KH wrote:
> > On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> >
> * Renamed Directory trees: The above problem is compounded with
> directory trees. Changing the name at the top of a large,
On Fri, Jun 15, 2007 at 05:42:08PM -0400, James Morris wrote:
> On Fri, 15 Jun 2007, Greg KH wrote:
>
> > > Or just create the files with restrictive labels by default. That way
> > > you "fail closed".
> >
> > From my limited knowledge of SELinux, this is the default today so this
> > would happ
Hi!
> > Yes, you may get some -EPERM during the tree move, but AA has that
> > problem already, see that "when madly moving trees we sometimes
> > construct path file never ever had".
>
> Pavel, please focus on the current AppArmor implementation. You're
> remembering a flaw with a previous versi
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
> Yes, you may get some -EPERM during the tree move, but AA has that
> problem already, see that "when madly moving trees we sometimes
> construct path file never ever had".
Pavel, please focus on the current AppArmor implementation. Yo
Greg KH wrote:
> On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
>
* Renamed Directory trees: The above problem is compounded with
directory trees. Changing the name at the top of a large, bushy
tree can require instant relabeling of millions of files
--- Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> >
> > Yup, I see that once you accept the notion that it is OK for a
> > file to be misslabeled for a bit and that having a fixxerupperd
> > is sufficient it all falls out.
> >
> > My poi
On Fri, 2007-06-15 at 14:44 -0700, Greg KH wrote:
> On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> > On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > > >
> > > > Yup, I see that once you accept the notio
On Fri, Jun 15, 2007 at 05:28:35PM -0400, Karl MacMillan wrote:
> On Fri, 2007-06-15 at 14:14 -0700, Greg KH wrote:
> > On Fri, Jun 15, 2007 at 01:43:31PM -0700, Casey Schaufler wrote:
> > >
> > > Yup, I see that once you accept the notion that it is OK for a
> > > file to be misslabeled for a bit
1 - 100 of 163 matches
Mail list logo
