On Mon, 2007-06-04 at 15:44 -0400, James Morris wrote:
On Mon, 4 Jun 2007, Eric Paris wrote:
Some time ago this thread bounced back and forth and seemed to come to
rest with the patch below, I cleaned up the comments and put all the
ACKs it received in one place below, but so much time
Some time ago this thread bounced back and forth and seemed to come to
rest with the patch below, I cleaned up the comments and put all the
ACKs it received in one place below, but so much time has passed I doubt
if they should still count for free. I also rediffed the patch against
the latest
On Mon, 4 Jun 2007, Eric Paris wrote:
Some time ago this thread bounced back and forth and seemed to come to
rest with the patch below, I cleaned up the comments and put all the
ACKs it received in one place below, but so much time has passed I doubt
if they should still count for free. I
I've applied this patch to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-davem
Dave, feel free to pull from that branch.
- James
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
From: James Morris [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 19:13:10 -0400 (EDT)
I've applied this patch to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-davem
Dave, feel free to pull from that branch.
Thanks James, I'll pull that in for my next round of
On Thu, 2007-03-22 at 20:56 -0400, James Morris wrote:
On Thu, 22 Mar 2007, Joy Latten wrote:
Perhaps a better semantic would be to fail the entire flush operation if
one of the security checks failed. e.g. loop through for permissions
first, then if all ok, loop through for deletion.
On Mon, 26 Mar 2007, Joy Latten wrote:
Signed-off-by: Joy Latten[EMAIL PROTECTED]
This looks ok to me, although I have a couple of minor issues (which
should probably not stop it being merged):
+ if ((err = security_xfrm_policy_delete(pol)) != 0) {
The value of 'err' is
On Mon, 26 Mar 2007, James Morris wrote:
On Mon, 26 Mar 2007, Joy Latten wrote:
Signed-off-by: Joy Latten[EMAIL PROTECTED]
This looks ok to me, although I have a couple of minor issues (which
should probably not stop it being merged):
+ if ((err =
On Mon, 2007-03-26 at 13:39 -0600, Joy Latten wrote:
+ if ((err = security_xfrm_policy_delete(pol)) != 0) {
+ xfrm_audit_log(audit_info-loginuid,
+audit_info-secid,
+
I have made improvements based on James' and Eric's comments.
Regards,
Joy
Signed-off-by: Joy Latten[EMAIL PROTECTED]
diff -urpN linux-2.6.20.orig/include/net/xfrm.h
linux-2.6.20.patch/include/net/xfrm.h
--- linux-2.6.20.orig/include/net/xfrm.h2007-03-23 11:01:48.0
-0500
+++
Sending again since one of the email addresses was incorrect.
Ok, I have made improvements based on James' and Eric's comments.
Regards,
Joy
Signed-off-by: Joy Latten[EMAIL PROTECTED]
diff -urpN linux-2.6.20.orig/include/net/xfrm.h
linux-2.6.20.patch/include/net/xfrm.h
---
On Mon, 26 Mar 2007, Joy Latten wrote:
Sending again since one of the email addresses was incorrect.
Ok, I have made improvements based on James' and Eric's comments.
Acked-by: James Morris [EMAIL PROTECTED]
+ if (xfrm_id_proto_match(x-id.proto,
On Fri, 2007-03-23 at 01:39 -0400, Eric Paris wrote:
In either case though proper auditing needs to be addressed. I see that
the first patch from Joy wouldn't audit deletion failures. It appears
to me if the check is done per policy then the security hook return code
needs to be recorded
On Fri, 2007-03-23 at 10:33 -0600, Joy Latten wrote:
On Fri, 2007-03-23 at 01:39 -0400, Eric Paris wrote:
In either case though proper auditing needs to be addressed. I see that
the first patch from Joy wouldn't audit deletion failures. It appears
to me if the check is done per
On Fri, 23 Mar 2007, Eric Paris wrote:
Maybe I'm way out on a limb here but if I am a regular user and I say
rm /tmp/* and I only have permissions to delete some of the files I
expect just those couple to be delete, not the whole operation denied.
I don't think this analogy holds up, as rm is
From: James Morris [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 14:46:48 -0400 (EDT)
A 'flush' has a semantic implication that all entries will be removed, and
it should be atomic and either succeed or fail at that granularity.
Correct.
-
To unsubscribe from this list: send the line unsubscribe
On Fri, 2007-03-23 at 11:47 -0700, David Miller wrote:
From: James Morris [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 14:46:48 -0400 (EDT)
A 'flush' has a semantic implication that all entries will be removed, and
it should be atomic and either succeed or fail at that granularity.
On Fri, 2007-03-23 at 12:59 -0400, Eric Paris wrote:
On Fri, 2007-03-23 at 10:33 -0600, Joy Latten wrote:
On Fri, 2007-03-23 at 01:39 -0400, Eric Paris wrote:
In either case though proper auditing needs to be addressed. I see that
the first patch from Joy wouldn't audit deletion
Within selinux we check for authorization before deleting entries from
SAD and SPD.
We are not checking for authorization when flushing the SPD and
the SAD. It was perhaps missed in original patch.
This patch adds security check when flushing entries from SAD and SPD.
Please let me know if
From: Joy Latten [EMAIL PROTECTED]
Date: Thu, 22 Mar 2007 12:35:39 -0600
Within selinux we check for authorization before deleting entries from
SAD and SPD.
We are not checking for authorization when flushing the SPD and
the SAD. It was perhaps missed in original patch.
This patch adds
On Thu, 2007-03-22 at 12:01 -0700, David Miller wrote:
From: Joy Latten [EMAIL PROTECTED]
Date: Thu, 22 Mar 2007 12:35:39 -0600
Within selinux we check for authorization before deleting entries from
SAD and SPD.
We are not checking for authorization when flushing the SPD and
the
On Thu, 22 Mar 2007, Joy Latten wrote:
I would look at this patch differently if there were some
security level key being checked for a match here, which is
an input key to the flush, but that is not what is happening
here as the object is being looked at by itself.
Yes, I understand
On Thu, 2007-03-22 at 19:49 -0400, James Morris wrote:
On Thu, 22 Mar 2007, Joy Latten wrote:
I would look at this patch differently if there were some
security level key being checked for a match here, which is
an input key to the flush, but that is not what is happening
here as
From: Eric Paris [EMAIL PROTECTED]
Date: Fri, 23 Mar 2007 01:39:47 -0400
It seems reasonable to me that the check for every policy (which is
between current-security-sid and xp-security-ctx_sid) makes sense.
There doesn't appear to me right offhand to be anything intrinsic in the
code which
24 matches
Mail list logo
