From: James Morris <[EMAIL PROTECTED]>
Date: Thu, 5 Oct 2006 16:58:31 -0400 (EDT)
> On Tue, 3 Oct 2006, David Miller wrote:
>
> > The socket policy behavior deserves some scrutiny. I say this because
> > if a matching socket policy is avoided due to security layer error,
> > this could potential
On Tue, 3 Oct 2006, David Miller wrote:
> The socket policy behavior deserves some scrutiny. I say this because
> if a matching socket policy is avoided due to security layer error,
> this could potentially make key manager problems very hard to
> diagnose.
In this case, AVC denial messages woul
l J Walsh
> Subject: Re: [PATCH] Fix for IPsec leakage with SELinux enabled - V.02
>
>
> On Wed, 4 Oct 2006, Evgeniy Polyakov wrote:
>
> > Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686
> i686 i386 GNU/Linux
> > [EMAIL PROTECTED] ~]# rpm -q selinux-policy-tar
On Tue, Oct 03, 2006 at 04:18:07PM -0700, David Miller wrote:
>
> As I review this patch I realize there is a question of
> semantics and prioritization here.
Indeed. Unfortunately I was doing other things at the time
sub-policies were introduced so I didn't pay attention to it.
After a quick l
On Wed, 4 Oct 2006, Evgeniy Polyakov wrote:
> Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686 i686 i386 GNU/Linux
> [EMAIL PROTECTED] ~]# rpm -q selinux-policy-targeted
> selinux-policy-targeted-2.3.17-2
>
> I get only this messages in audit.log when remote racoon tries to
> connect to
On Mon, Oct 02, 2006 at 12:41:57PM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> You can get recent policy packages via the devel repo, which I'd suggest
> if you're using development (or DIY) kernels.
[EMAIL PROTECTED] ~]# uname -a
Linux kano 2.6.18 #5 SMP Mon Oct 2 18:44:30 MSD 2006 i686 i6
On Tue, 3 Oct 2006, David Miller wrote:
> I'm not saying either is wrong, I'm just pointing it out to make sure
> this is intentional.
>
> The socket policy behavior deserves some scrutiny. I say this because
> if a matching socket policy is avoided due to security layer error,
> this could pote
From: James Morris <[EMAIL PROTECTED]>
Date: Mon, 2 Oct 2006 10:27:13 -0400 (EDT)
> Updated version of the patch, which return directly after a flow cache
> lookup error in xfrm_lookup rather than returing via the cleanup path
> (which was causing a spurious dst_release).
>
> This works for me,
> > This is indeed the "designed" and expected (for me) behavior.
>
> This is a security hole. SELinux denies all access by
> default, so the
> default behavior of this code is to allow all traffic to bypass IPsec.
>
> You should not need to add a rule to 'allow' increased security.
You are r
On Mon, 2 Oct 2006, Venkat Yekkirala wrote:
> This is indeed the "designed" and expected (for me) behavior.
This is a security hole. SELinux denies all access by default, so the
default behavior of this code is to allow all traffic to bypass IPsec.
You should not need to add a rule to 'allow'
> On Sun, 1 Oct 2006, Venkat Yekkirala wrote:
>
> > > The way I was seeing the problem was when connecting via
> IPsec to a
> > > confined service on an SELinux box (vsftpd), which did
> not have the
> > > appropriate SELinux policy permissions to send packets via IPsec.
> > >
> > > The first
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> > Can you look in /var/log/audit/audit.log ? (especially grep for
> > 'association' )
>
> Indeed.
>
> type=AVC msg=audit(1159804556.391:21): avc: denied { polmatch } for
> pid=2213 comm="racoon" scontext=root:system_r:unconfined_t:s0-s0:c0.c255
>
On Mon, Oct 02, 2006 at 12:13:45PM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
>
> > On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris ([EMAIL PROTECTED])
> > wrote:
> > > Updated version of the patch, which return directly after a flow cache
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris ([EMAIL PROTECTED])
> wrote:
> > Updated version of the patch, which return directly after a flow cache
> > lookup error in xfrm_lookup rather than returing via the cleanup path
> > (which was c
On Mon, Oct 02, 2006 at 10:27:13AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> Updated version of the patch, which return directly after a flow cache
> lookup error in xfrm_lookup rather than returing via the cleanup path
> (which was causing a spurious dst_release).
>
> This works for me,
Updated version of the patch, which return directly after a flow cache
lookup error in xfrm_lookup rather than returing via the cleanup path
(which was causing a spurious dst_release).
This works for me, although I never saw the oops with the old patch.
Evgeniy, let me know if this fixes the oo
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> Probably reference counter is inside freed object...
I think I know what it is (xfrm_lookup needs to just return on flow cache
lookup failure, not goto error and free the dst). Patch forthcoming.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To
On Mon, Oct 02, 2006 at 09:31:36AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> What kind of traffic was running over the system? What is the IPsec and
> SELinux configuration?
I had login through ssh, started racoon and setup keys.
SElinu is configured by default in FC5 system with enforci
On Mon, 2 Oct 2006, Evgeniy Polyakov wrote:
> > Evgeniy, please let me know if this fixes your problem.
>
> With that patch applied I got kernel panic after some time.
> Unfortunately I have not installed serial console, so the most
> interesting bits of the stack dump are not visible.
> Here is
On Sun, Oct 01, 2006 at 02:27:13AM -0400, James Morris ([EMAIL PROTECTED])
wrote:
> Please review this patch carefully. It addresses a couple of issues.
>
> When a security module is loaded (in this case, SELinux), the
> security_xfrm_policy_lookup() hook can return an access denied permission
On Sun, 1 Oct 2006, Venkat Yekkirala wrote:
> > The way I was seeing the problem was when connecting via IPsec to a
> > confined service on an SELinux box (vsftpd), which did not have the
> > appropriate SELinux policy permissions to send packets via IPsec.
> >
> > The first SYNACK would be blo
> The way I was seeing the problem was when connecting via IPsec to a
> confined service on an SELinux box (vsftpd), which did not have the
> appropriate SELinux policy permissions to send packets via IPsec.
>
> The first SYNACK would be blocked,
Given that the resolver fails to find a policy h
Please review this patch carefully. It addresses a couple of issues.
When a security module is loaded (in this case, SELinux), the
security_xfrm_policy_lookup() hook can return an access denied permission
(or other error). We were not handling that correctly, and in fact
inverting the return
23 matches
Mail list logo
