Pathname matching, transition table loading, profile loading and
manipulation.
Signed-off-by: John Johansen [EMAIL PROTECTED]
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
---
security/apparmor/match.c| 273 +++
security/apparmor/match.h| 85 +++
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
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 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.
Your
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 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 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 mediation. 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 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 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 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
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 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
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
[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
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:
snip
Um, no. It might not be able to directly open files via that
--- 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
properly if it shows up.
In our 1995 B1 evaluation of Trusted
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, 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 is that there is a segment of the security community
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, 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 [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 point is that
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
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
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 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:
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.
On Sat, 9 Jun 2007, Sean wrote:
remember that the security hooks in the kernel are not SELinux API's, they
are the Loadable Security Model API. What the AA people are asking for is
for the LSM API to be modified enough to let their code run (after that
(and working in parallel) they will work on
On Saturday 09 June 2007 10:10, Sean wrote:
Clinging to the current AA implementation instead of honestly considering
reasonable alternatives does not inspire confidence or teamwork.
What you imply is pretty insulting. I can assure you we looked into many
possible implementation choices, and
[EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Sean wrote:
snip
what SELinux cannot do is figure out what label to assign a new file.
Nit: SELinux figures out what to label new files fine, just not based on
the name. This works in most cases, eg., when user_t creates a file in
/tmp it
On Jun 09, 2007, at 01:18:40, [EMAIL PROTECTED] wrote:
SELinux is like a default allow IPS system, you have to describe
EVERYTHING to the system so that it knows what to allow and what to
stop.
WRONG. You clearly don't understand SELinux at all. Try booting in
enforcing mode with an
On Sat, 9 Jun 2007 17:17:57 +0200
Andreas Gruenbacher [EMAIL PROTECTED] wrote:
On Saturday 09 June 2007 10:10, Sean wrote:
Clinging to the current AA implementation instead of honestly considering
reasonable alternatives does not inspire confidence or teamwork.
What you imply is pretty
On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 01:18:40, [EMAIL PROTECTED] wrote:
SELinux is like a default allow IPS system, you have to describe EVERYTHING
to the system so that it knows what to allow and what to stop.
WRONG. You clearly don't understand SELinux at all. Try
On Jun 09, 2007, at 12:46:40, [EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
Typical targetted policies leave all user logins as
unrestricted, adding security for daemons but not getting in the
way of users who would otherwise turn SELinux off. On the other
hand, a
On Sat, 9 Jun 2007, Kyle Moffett wrote:
On Jun 09, 2007, at 12:46:40, [EMAIL PROTECTED] wrote:
On Sat, 9 Jun 2007, Kyle Moffett wrote:
Typical targetted policies leave all user logins as unrestricted,
adding security for daemons but not getting in the way of users who would
otherwise turn
--- Sean [EMAIL PROTECTED] wrote:
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
On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
[...] SELinux turns pathnames into labels when it
initially labels all files (when a policy is rolled out), whereas
AppArmor computes the label of each file when a file is
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.
Woah, that describes the userspace side of AA just fine, it means
nothing when it comes
Hello.
David Lang wrote:
as I understand it SELinux puts one label on each file, so if you have
three files accessed by two programs such that
program A accesses files X Y
program B accesses files Y Z
then files X Y and Z all need separate labels with the policy stateing
that program A
On Sat, 9 Jun 2007 11:01:41 +0900
Tetsuo Handa [EMAIL PROTECTED] wrote:
From the discussion so far, it seems that the different model that AA
is trying to implement, is to do in one step what SELinux does in two
steps; that is trying to combine labelling and enforcement into a
single step. If
On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
Hi!
Pathname matching, transition table loading, profile loading and
manipulation.
So we get small interpretter of state machines, and reason we need is
is 'apparmor
Hi!
Pathname matching, transition table loading, profile loading and
manipulation.
So we get small interpretter of state machines, and reason we need is
is 'apparmor is misdesigned and works with paths when it should have
worked with handles'.
If you solve the 'new file problem', aa becomes
Pathname matching, transition table loading, profile loading and
manipulation.
Signed-off-by: John Johansen [EMAIL PROTECTED]
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
---
security/apparmor/match.c| 232
security/apparmor/match.h| 83
67 matches
Mail list logo
