Add a policy directory to features to contain features that can affect
policy compilation but do not affect mediation. Eg of such features would
be types of dfa compression supported, etc.
Signed-off-by: John Johansen john.johan...@canonical.com
Acked-by: Kees Cook k...@ubuntu.com
---
security
Signed-off-by: John Johansen john.johan...@canonical.com
---
security/apparmor/lsm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 2e2a0dd..96506df 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
by making the ns and its unconfined
profile share the same refcount.
Signed-off-by: John Johansen john.johan...@canonical.com
Acked-by: Seth Arnold seth.arn...@canonical.com
---
security/apparmor/domain.c | 2 +-
security/apparmor/include/policy.h | 80
On 04/24/2013 02:15 PM, Paul Moore wrote:
> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
>> On 4/24/2013 11:57 AM, Paul Moore wrote:
>>> I know we had a good discussion about this a while back and I just wanted
>>> to hear from you about this current patchset; how does the
On 04/24/2013 02:15 PM, Paul Moore wrote:
On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:
On 4/24/2013 11:57 AM, Paul Moore wrote:
I know we had a good discussion about this a while back and I just wanted
to hear from you about this current patchset; how does the labeled
On 01/10/2013 05:13 PM, Eric W. Biederman wrote:
> John Johansen writes:
>
>>> When a distro is run in a container it is desirable to be able to run
>>> the distro's security policy in that container. Ideally this will get
>>> addressed by being able to do
On 01/10/2013 04:46 PM, Eric W. Biederman wrote:
> John Johansen writes:
>
>> On 01/09/2013 05:28 AM, James Morris wrote:
>>> On Tue, 8 Jan 2013, John Johansen wrote:
>>>
>>>>> I'd say we need to see the actual use-case for Smack and Apparmor being
On 01/09/2013 05:28 AM, James Morris wrote:
> On Tue, 8 Jan 2013, John Johansen wrote:
>
>>> I'd say we need to see the actual use-case for Smack and Apparmor being
>>> used together, along with at least one major distro committing to support
>>> this.
>
On 01/10/2013 04:46 PM, Eric W. Biederman wrote:
John Johansen john.johan...@canonical.com writes:
On 01/09/2013 05:28 AM, James Morris wrote:
On Tue, 8 Jan 2013, John Johansen wrote:
I'd say we need to see the actual use-case for Smack and Apparmor being
used together, along
On 01/10/2013 05:13 PM, Eric W. Biederman wrote:
John Johansen john.johan...@canonical.com writes:
When a distro is run in a container it is desirable to be able to run
the distro's security policy in that container. Ideally this will get
addressed by being able to do some level of per user
On 01/09/2013 05:28 AM, James Morris wrote:
On Tue, 8 Jan 2013, John Johansen wrote:
I'd say we need to see the actual use-case for Smack and Apparmor being
used together, along with at least one major distro committing to support
this.
Ubuntu is very interested in stacking
Which
On 01/08/2013 01:12 AM, James Morris wrote:
> On Mon, 7 Jan 2013, Casey Schaufler wrote:
>
>> There has been an amazing amount of development in system security
>> over the past three years. Almost none of it has been in the kernel.
>> One important reason that it is not getting done in the
On 01/08/2013 09:47 AM, Stephen Smalley wrote:
> On 01/07/2013 08:54 PM, Casey Schaufler wrote:
>> Subject: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
>>
>> Change the infrastructure for Linux Security Modules (LSM)s
>> from a single vector of hook handlers to a list based method
>> for
On 01/08/2013 09:47 AM, Stephen Smalley wrote:
On 01/07/2013 08:54 PM, Casey Schaufler wrote:
Subject: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
Change the infrastructure for Linux Security Modules (LSM)s
from a single vector of hook handlers to a list based method
for handling multiple
On 01/08/2013 01:12 AM, James Morris wrote:
On Mon, 7 Jan 2013, Casey Schaufler wrote:
There has been an amazing amount of development in system security
over the past three years. Almost none of it has been in the kernel.
One important reason that it is not getting done in the kernel is
On 11/13/2012 07:58 PM, Kees Cook wrote:
> Stop using spinlocks in the read path. Add RCU list to handle the readers.
>
> Signed-off-by: Kees Cook
Looks good to me
Acked-by: John Johansen
> ---
> security/yama/yama_lsm.c | 43 ---
&g
On 11/13/2012 07:58 PM, Kees Cook wrote:
Stop using spinlocks in the read path. Add RCU list to handle the readers.
Signed-off-by: Kees Cook keesc...@chromium.org
Looks good to me
Acked-by: John Johansen john.johan...@canonical.com
---
security/yama/yama_lsm.c | 43
ability.h
> However, capability.h was moved to include/uapi/linux/capability.h and
> because
> of this, the array is empty.
> That's why, sa->u.cap become out of range this and segmentation fault caused.
>
> Let's fix it.
>
> Cc: James Morris
> Cc: John Johansen
/linux/capability.h and
because
of this, the array is empty.
That's why, sa-u.cap become out of range this and segmentation fault caused.
Let's fix it.
Cc: James Morris james.l.mor...@oracle.com
Cc: John Johansen john.johan...@canonical.com
Thanks Hiromu,
but this was fixed a few hours
On 09/20/2012 07:22 PM, James Morris wrote:
> On Thu, 20 Sep 2012, Kees Cook wrote:
>
>> Earlier proposals for appending signatures to kernel modules would not be
>> useful in Chrome OS, since it would involve adding an additional set of
>> keys to our kernel and builds for no good reason: we
On 09/20/2012 07:22 PM, James Morris wrote:
On Thu, 20 Sep 2012, Kees Cook wrote:
Earlier proposals for appending signatures to kernel modules would not be
useful in Chrome OS, since it would involve adding an additional set of
keys to our kernel and builds for no good reason: we already
Y || (int)arg2 == -1) {
> rc = yama_ptracer_add(NULL, myself);
> } else {
> struct task_struct *tracer;
>
yeah this looks good it should at least hit stable
Acked-by: John Johansen
--
To unsubscribe from this list: send the line &
to Kees off list. But I don't have an
> answer either.
>
> Acked-by: Eric Paris
>
Yeah I'm not fond of it either but until some more generic form of LSM
stacking arives, I don't see a good alternative either
so until then
Acked-by: John Johansen
--
To unsubscribe f
Yeah I'm not fond of it either but until some more generic form of LSM
stacking arives, I don't see a good alternative either
so until then
Acked-by: John Johansen john.johan...@canonical.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
);
} else {
struct task_struct *tracer;
yeah this looks good it should at least hit stable
Acked-by: John Johansen john.johan...@canonical.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 08/07/2012 03:17 PM, Serge E. Hallyn wrote:
> Quoting Paul Moore (p...@paul-moore.com):
>> On Tue, Aug 7, 2012 at 5:58 PM, John Stultz wrote:
>>> On 08/07/2012 02:50 PM, Paul Moore wrote:
On Tue, Aug 7, 2012 at 2:12 PM, John Stultz
wrote:
>
> Hi,
> With my kvm
On 08/07/2012 03:17 PM, Serge E. Hallyn wrote:
Quoting Paul Moore (p...@paul-moore.com):
On Tue, Aug 7, 2012 at 5:58 PM, John Stultz john.stu...@linaro.org wrote:
On 08/07/2012 02:50 PM, Paul Moore wrote:
On Tue, Aug 7, 2012 at 2:12 PM, John Stultz john.stu...@linaro.org
wrote:
Hi,
ng Wu
> Suggested-by: Oleg Nesterov
> Cc: sta...@vger.kernel.org
> Signed-off-by: Kees Cook
yep, looks good
Acked-by: John Johansen
> ---
> security/yama/yama_lsm.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/security/yama/yama_lsm.c
Suggested-by: Oleg Nesterov o...@redhat.com
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook keesc...@chromium.org
yep, looks good
Acked-by: John Johansen john.johan...@canonical.com
---
security/yama/yama_lsm.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git
On Mon, Nov 12, 2007 at 03:50:59PM -0800, Crispin Cowan wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >
> >> I mostly don't see this as a serious limitation, because almost everyone
> >> has their own workstation, and thus has root on that workstation.
On Mon, Nov 12, 2007 at 03:50:59PM -0800, Crispin Cowan wrote:
Dr. David Alan Gilbert wrote:
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
I mostly don't see this as a serious limitation, because almost everyone
has their own workstation, and thus has root on that workstation. There
are
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
>
>
> a question for Crispin,
> is there a wildcard replacement for username? so that you could grant
> permission to /home/$user/.mozilla.. and grant each user access
On Sat, Nov 10, 2007 at 05:27:51PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
>
>>> but how can the system know if the directory the user wants to add is
>>> reasonable or not? what if the user says they want to store their
>>> documents in /etc?
>>
>> A more clear
I would like to better understand the problem here.
> >
> > Note that John Johansen is also interested in allowing non-privileged
> > users to manipulate AppArmor policy, but his view was to only allow a
> > non-privileged user to further tighten the profile on a program. To m
On Sat, Nov 10, 2007 at 01:28:25PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Andi Kleen wrote:
>
>> Crispin Cowan <[EMAIL PROTECTED]> writes:
>>
>> The document should be a good base for a merge.
>>
>>> * A confined process can operate on a file descriptor passed to it
>>>
On Sat, Nov 10, 2007 at 01:24:46PM -0800, Crispin Cowan wrote:
> Andi Kleen wrote:
> > Crispin Cowan <[EMAIL PROTECTED]> writes:
> >
> > The document should be a good base for a merge.
> >
> >
> >> * A confined process can operate on a file descriptor passed to it
> >> by an
On Sat, Nov 10, 2007 at 01:24:46PM -0800, Crispin Cowan wrote:
Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined process, even if
On Sat, Nov 10, 2007 at 01:28:25PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Andi Kleen wrote:
Crispin Cowan [EMAIL PROTECTED] writes:
The document should be a good base for a merge.
* A confined process can operate on a file descriptor passed to it
by an unconfined
that John Johansen is also interested in allowing non-privileged
users to manipulate AppArmor policy, but his view was to only allow a
non-privileged user to further tighten the profile on a program. To me,
that adds complexity with not much value, but if lots of users want it,
then I'm wrong
On Sat, Nov 10, 2007 at 05:27:51PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Alan Cox wrote:
but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?
A more clear example is wanting
On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
snip
a question for Crispin,
is there a wildcard replacement for username? so that you could grant
permission to /home/$user/.mozilla.. and grant each user access to
On Fri, Oct 26, 2007 at 01:30:52PM +0200, Miklos Szeredi wrote:
> On Thu, 2007-10-25 at 23:40 -0700, [EMAIL PROTECTED] wrote:
> > plain text document attachment (file-handle-ops.diff)
> > Struct iattr already contains ia_file since commit cc4e69de from
> > Miklos (which is related to commit
On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> On Thu, 25 Oct 2007 23:40:24 -0700
> [EMAIL PROTECTED] wrote:
>
> before going into the LSM / security side of things, I'd like to get
> the VFS guys to look at your VFS interaction code.
>
yes, the vfs interaction definitely
ion functions to tell between parent and leaf checks.
> >
> > Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
> > Signed-off-by: John Johansen <[EMAIL PROTECTED]>
> >
> > ---
> > fs/namei.c |6 ++
> > 1 file changed, 6 insertion
On Fri, Oct 26, 2007 at 08:37:49AM +0100, Al Viro wrote:
> On Thu, Oct 25, 2007 at 11:40:43PM -0700, [EMAIL PROTECTED] wrote:
> > The vfsmount will be passed down to the LSM hook so that LSMs can compute
> > pathnames.
>
> You know, you really are supposed to understand the code you are
On Thu, Oct 25, 2007 at 11:40:24PM -0700, [EMAIL PROTECTED] wrote:
Sorry this got dropped some how.
This submission of the AppArmor security module is based against -mm.
Any comments and feedback to improve implementation are appreciated.
The patch series consists of five areas:
(1) Pass
On Thu, Oct 25, 2007 at 11:40:24PM -0700, [EMAIL PROTECTED] wrote:
Sorry this got dropped some how.
This submission of the AppArmor security module is based against -mm.
Any comments and feedback to improve implementation are appreciated.
The patch series consists of five areas:
(1) Pass
On Fri, Oct 26, 2007 at 08:37:49AM +0100, Al Viro wrote:
On Thu, Oct 25, 2007 at 11:40:43PM -0700, [EMAIL PROTECTED] wrote:
The vfsmount will be passed down to the LSM hook so that LSMs can compute
pathnames.
You know, you really are supposed to understand the code you are modifying...
between parent and leaf checks.
Signed-off-by: Andreas Gruenbacher [EMAIL PROTECTED]
Signed-off-by: John Johansen [EMAIL PROTECTED]
---
fs/namei.c |6 ++
1 file changed, 6 insertions(+)
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1472,6 +1472,10 @@ static int may_delete(struct
On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
On Thu, 25 Oct 2007 23:40:24 -0700
[EMAIL PROTECTED] wrote:
before going into the LSM / security side of things, I'd like to get
the VFS guys to look at your VFS interaction code.
yes, the vfs interaction definitely need
On Fri, Oct 26, 2007 at 01:30:52PM +0200, Miklos Szeredi wrote:
On Thu, 2007-10-25 at 23:40 -0700, [EMAIL PROTECTED] wrote:
plain text document attachment (file-handle-ops.diff)
Struct iattr already contains ia_file since commit cc4e69de from
Miklos (which is related to commit befc649c).
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen <[EMAIL PROTECTED]> wrote:
>
> > >
> > > so... where do we stand with this? Fundamental, irreconcilable
> > > differences
On Tue, Jun 26, 2007 at 07:47:00PM -0700, Andrew Morton wrote:
On Tue, 26 Jun 2007 19:24:03 -0700 John Johansen [EMAIL PROTECTED] wrote:
so... where do we stand with this? Fundamental, irreconcilable
differences over the use of pathname-based security?
There certainly seems
On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
> On Tue, 26 Jun 2007 16:07:56 -0700
> [EMAIL PROTECTED] wrote:
>
> > This post contains patches to include the AppArmor application security
> > framework, with request for inclusion into -mm for wider testing.
>
> Patches 24 and 31
On Tue, Jun 26, 2007 at 04:52:02PM -0700, Andrew Morton wrote:
On Tue, 26 Jun 2007 16:07:56 -0700
[EMAIL PROTECTED] wrote:
This post contains patches to include the AppArmor application security
framework, with request for inclusion into -mm for wider testing.
Patches 24 and 31 didn't
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
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
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 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 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
sigh, and with the intoductory text attached
This post is a request for discussion on creating a second minimal
nameidata struct to eliminate conditionally passing of vfsmounts
to the LSM.
It contains a series of patches that apply on top of the AppArmor
patch series. A previous version of
and with the actual introductory text this time
This post contains patches to include the AppArmor application security
framework, with request for inclusion. It contains fixes for almost
all of the feedback received from the previous post. A second follow
up posting will address passing NULL
and with the actual introductory text this time
This post contains patches to include the AppArmor application security
framework, with request for inclusion. It contains fixes for almost
all of the feedback received from the previous post. A second follow
up posting will address passing NULL
sigh, and with the intoductory text attached
This post is a request for discussion on creating a second minimal
nameidata struct to eliminate conditionally passing of vfsmounts
to the LSM.
It contains a series of patches that apply on top of the AppArmor
patch series. A previous version of
On Mon, Apr 16, 2007 at 11:00:01PM +0100, Alan Cox wrote:
> > don't actually have to care --- if loading an invalid profile can bring
> > down
> > the system, then that's no worse than an arbitrary module that crashes the
> > machine. Not sure if there will ever be user loadable profiles; at
On Thu, Apr 12, 2007 at 11:21:01AM +0100, Alan Cox wrote:
> > +
> > + /**
> > +* parent can ptrace child when
> > +* - parent is unconfined
> > +* - parent is in complain mode
> > +* - parent and child are confined by the same profile
> > +*/
>
> Your profiles are name
Here we present our direct responses to the most frequent questions from
the AppArmor from the 2006 post.
Use of Pathnames For Access Control
---
Some people in the security field believe that pathnames are an
inappropriate security mechanism. This depends on
On Mon, Apr 16, 2007 at 08:27:08AM +0200, Andi Kleen wrote:
> > It's nice to check for consistency though, so we're adding that. Profile
> > loading is a trusted operation, at least so far, and so security wise we
> > don't actually have to care --- if loading an invalid profile can bring
> >
On Mon, Apr 16, 2007 at 08:27:08AM +0200, Andi Kleen wrote:
It's nice to check for consistency though, so we're adding that. Profile
loading is a trusted operation, at least so far, and so security wise we
don't actually have to care --- if loading an invalid profile can bring
down
Here we present our direct responses to the most frequent questions from
the AppArmor from the 2006 post.
Use of Pathnames For Access Control
---
Some people in the security field believe that pathnames are an
inappropriate security mechanism. This depends on
On Thu, Apr 12, 2007 at 11:21:01AM +0100, Alan Cox wrote:
+
+ /**
+* parent can ptrace child when
+* - parent is unconfined
+* - parent is in complain mode
+* - parent and child are confined by the same profile
+*/
Your profiles are name based. That means the
On Mon, Apr 16, 2007 at 11:00:01PM +0100, Alan Cox wrote:
don't actually have to care --- if loading an invalid profile can bring
down
the system, then that's no worse than an arbitrary module that crashes the
machine. Not sure if there will ever be user loadable profiles; at least at
401 - 473 of 473 matches
Mail list logo
