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).
Pavel,
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 could be
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 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
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_
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. I'm
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 the use the
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 feature, not
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...
(Or
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.
Or
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 processed
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.
I bet you don't
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 doesn't
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
court
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 the use the
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 have to
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 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
temporary file
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 mediation. The
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 arising
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 the server as
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 the former, I'd
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
--- 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 under
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 the
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
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:
* 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 to
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 concerns
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
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 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
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
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 believe
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.
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. if it
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
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 believe it
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
filesystem
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 change the
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 apps,
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't actually
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, 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 have other
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote:
snip
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
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.
--
Teamlead
On Thu, 21 Jun 2007, Joshua Brindle wrote:
Lars Marowsky-Bree wrote:
On 2007-06-21T16:59:54, Stephen Smalley [EMAIL PROTECTED] wrote:
snip
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
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 is ugly, yuk
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 likewise
[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:
snip
Um, no. It might not be able to directly open files via that
path, but
showing that it can never read or write your
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 object type
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 manner
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 label the file
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 wrote:
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. AA is
--- 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
That's an eternity for
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
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 paths that might
On Sun, Jun 10, 2007 at 10:09:18AM -0700, Crispin Cowan wrote:
Andreas Gruenbacher wrote:
On Saturday 09 June 2007 02:17, Greg KH wrote:
On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
AppArmor is meant to be relatively easy to understand, manage, and
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 label the file
properly if it shows up.
In our 1995 B1 evaluation of Trusted Irix we were told in no
uncertain terms that such a
--- Greg KH [EMAIL PROTECTED] wrote:
A daemon using inotify can instantly[1] detect this and label the file
properly if it shows up.
In our 1995 B1 evaluation of Trusted Irix we were told in no
uncertain terms that such a solution was not acceptable under
the TCSEC requirements. Detection
Hi!
And before you scream races, take a look. It does not actually add
them:
I agree that the in-kernel implementation could use different
abstractions
than user-space, provided that the underlying implementation details can
be
hidden well enough. The key phrase here is if
On Fri, Jun 15, 2007 at 10:06:23PM +0200, Pavel Machek wrote:
Hi!
And before you scream races, take a look. It does not actually add
them:
Hey, I never screamed that at all, in fact, I completly agree with you
:)
I agree that the in-kernel implementation could use different
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 and that having a fixxerupperd
is sufficient it all falls out.
My point
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 happen by default. Anyone with more SELinux experience want to
verify or fix my
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 and that
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 notion that it is
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.
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. You're
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 version of
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 happen by default.
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, bushy
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
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 already, see that when
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, I did
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
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 period of time,
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? You are
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 _can't_ be keeping
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
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, 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 already
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
--- 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
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.
If, and
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 talking
[EMAIL PROTECTED] wrote:
On Sun, 10 Jun 2007, Pavel Machek wrote:
But you have that regex in _user_ space, in a place where policy
is loaded into kernel.
then the kernel is going to have to call out to userspace every time a
file is created or renamed and the policy is going to be enforced
On Thu, 14 Jun 2007, Jack Stone wrote:
[EMAIL PROTECTED] wrote:
On Sun, 10 Jun 2007, Pavel Machek wrote:
But you have that regex in _user_ space, in a place where policy
is loaded into kernel.
then the kernel is going to have to call out to userspace every time a
file is created or renamed
On 2007-06-10T23:05:47, Pavel Machek [EMAIL PROTECTED] wrote:
But you have that regex in _user_ space, in a place where policy
is loaded into kernel.
AA has regex parser in _kernel_ space, which is very wrong.
That regex parser only applies user defined policy. The logical
connection
On Sun, 10 Jun 2007, Pavel Machek wrote:
extended out this can come close to giving each file it's own label. AA
essentially does this and calls the label the path and computes it at
runtime instead of storing it somewhere.
Yes, and in the process, AA stores compiled regular expressions in
On Sun, 10 Jun 2007, Crispin Cowan wrote:
Casey Schaufler wrote:
--- [EMAIL PROTECTED] wrote:
Yes, and in the process, AA stores compiled regular expressions in
kernel. Ouch. I'll take each file it's own label over _that_ any time.
and if each file has it's own label you are going to need
On Sun, 10 Jun 2007 23:45:16 -0700 (PDT)
[EMAIL PROTECTED] wrote:
say that we give each file a unique label, and for simplicity we set the
label == path (note that this raises the issue, what will SELinux do when
there are multiple paths to the same file)
So don't do that then.
now say
Hi!
ACPI should have taught everyone that sometimes putting an interpreter in
the kernel really is the best option. looking at the problems of bouncing
back out to userspace for file creation and renames it looks like a regex
in the kernel is a lot safer and more reliable.
What do ACPI
On Mon, 11 Jun 2007 02:33:30 -0700 (PDT)
[EMAIL PROTECTED] wrote:
Ok, you are proposing throwing out all the label handling that SELinux
does, including any caching. forgive me if I agree with the SELinux people
that this is a very bad idea.
Well presumably AA would be doing caching etc..
On Sat, 2007-06-09 at 00:03 +0200, Andreas Gruenbacher wrote:
On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
- under AA, each file may have an arbitrary set of labels or
policies applied to it depending on what programs are accessing it and
what names are being used to reference it
Hi!
So, AA developers, do you have such a document anywhere? I know there
are some old research papers, do they properly describe the current
model you are trying to implement here?
Greg,
to implement the AA approach useing SELinux you need to have a way that
files that are renamed or
On Sun, 10 Jun 2007, Pavel Machek wrote:
Hi!
So, AA developers, do you have such a document anywhere? I know there
are some old research papers, do they properly describe the current
model you are trying to implement here?
Greg,
to implement the AA approach useing SELinux you need to
Andreas Gruenbacher wrote:
On Saturday 09 June 2007 02:17, Greg KH wrote:
On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
AppArmor is meant to be relatively easy to understand, manage, and
customize, and introducing a labels layer wouldn't help these goals.
--- [EMAIL PROTECTED] wrote:
Yes, and in the process, AA stores compiled regular expressions in
kernel. Ouch. I'll take each file it's own label over _that_ any time.
and if each file has it's own label you are going to need regex or similar
to deal with them as well.
Now that you're
1 - 100 of 124 matches
Mail list logo
