Re: [PATCH] XFRM: RFC4303 compliant auditing
On Friday 07 December 2007 3:52:31 pm Eric Paris wrote: On Fri, 2007-12-07 at 14:57 -0500, Paul Moore wrote: NOTE: This really is an RFC patch, it compiles and boots but that is pretty much all I can promise at this point. I'm posting this patch to gather feedback from the audit crowd about the continued overloading of the AUDIT_MAC_IPSEC_EVENT message type - continue to use it or create a new audit message type? Of course any other comments people may have are always welcome. I'm all for continuing to use it, but I feel like the op= strings should probably all get collected up in one place to ease maintenance in the future, might not matter but it's nice to be able to look only on place in the code to find all of the possible op= Agreed. I punted on doing anything here for two main reasons: 1. It makes sense to do this in the xfrm_audit_start() function which I couldn't use here without some overhaul ... 2. ... I didn't want to overhaul anything if I was going to end up using separate message types. If we decide to go with a single audit message type (kinda sounds like it) I'll fix this up in the next version. The one advantage to multiple messages is the ability to exclude and not audit certain things. How often will these extra messages actually pop out of a system? Enough that people would likely still care about some of them but decide they don't want others? I don't know this stuff, so tell me how often would any of these show up? Bingo, this is the whole reason why I was wondering about a different message type. Currently only SAD and SPD changes are audited and only because they effect the security labels that are assigned to packets as they are imported/exported out of the system (look at the LSPP requirements for auditing the import and export of data). These new audit messages apply to individual packets and/or a particular SA and have nothing to do with security labels, rather they indicate error conditions found during normal IPsec processing. It would be difficult to think of all of the particular cases where these error conditions but in general I would say that these audit messages should not be common. The only reason for creating a separate audit message type for these packet/SA messages would be to meet a RFC requirement that states that the implementation MUST allow the administrator to enable and disable ESP auditing. Now, we can probably say we fulfill that requirement regardless, but more message types allow us greater granularity and flexibility ... -- paul moore linux security @ hp -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] XFRM: RFC4303 compliant auditing
On Fri, 2007-12-07 at 14:57 -0500, Paul Moore wrote:
NOTE: This really is an RFC patch, it compiles and boots but that is pretty
much all I can promise at this point. I'm posting this patch to gather
feedback from the audit crowd about the continued overloading of
the AUDIT_MAC_IPSEC_EVENT message type - continue to use it or create
a new audit message type? Of course any other comments people may have
are always welcome.
I'm all for continuing to use it, but I feel like the op= strings should
probably all get collected up in one place to ease maintenance in the
future, might not matter but it's nice to be able to look only on place
in the code to find all of the possible op=
The one advantage to multiple messages is the ability to exclude and not
audit certain things. How often will these extra messages actually pop
out of a system? Enough that people would likely still care about some
of them but decide they don't want others? I don't know this stuff, so
tell me how often would any of these show up?
-Eric
This patch adds a number of new IPsec audit events to meet the auditing
requirements of RFC4303. This includes audit hooks for the following events:
* Could not find a valid SA [sections 2.1, 3.4.2]
. xfrm_audit_state_notfound()
. xfrm_audit_state_notfound_simple()
* Sequence number overflow [section 3.3.3]
. xfrm_audit_state_replay_overflow()
* Replayed packet [section 3.4.3]
. xfrm_audit_state_replay()
* Integrity check failure [sections 3.4.4.1, 3.4.4.2]
. xfrm_audit_state_icvfail()
While RFC4304 deals only with ESP most of the changes in this patch apply to
IPsec in general, i.e. both AH and ESP. The one case, integrity check
failure, where ESP specific code had to be modified the same was done to the
AH code for the sake of consistency.
---
include/net/xfrm.h | 14
net/ipv4/ah4.c |1
net/ipv4/esp4.c|1
net/ipv4/xfrm4_input.c |6 +-
net/ipv6/ah6.c |1
net/ipv6/esp6.c|1
net/ipv6/xfrm6_input.c | 10 ++-
net/xfrm/xfrm_output.c |2 +
net/xfrm/xfrm_state.c | 155
++--
9 files changed, 177 insertions(+), 14 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index c02e230..85ce8c1 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -492,11 +492,22 @@ extern void xfrm_audit_state_add(struct xfrm_state *x,
int result,
u32 auid, u32 secid);
extern void xfrm_audit_state_delete(struct xfrm_state *x, int result,
u32 auid, u32 secid);
+extern void xfrm_audit_state_replay_overflow(struct xfrm_state *x,
+ struct sk_buff *skb);
+extern void xfrm_audit_state_notfound_simple(struct sk_buff *skb, u16
family);
+extern void xfrm_audit_state_notfound(struct sk_buff *skb, u16 family,
+ __be32 net_spi, __be32 net_seq);
+extern void xfrm_audit_state_icvfail(struct xfrm_state *x,
+ struct sk_buff *skb, u8 proto);
#else
#define xfrm_audit_policy_add(x, r, a, s)do { ; } while (0)
#define xfrm_audit_policy_delete(x, r, a, s) do { ; } while (0)
#define xfrm_audit_state_add(x, r, a, s) do { ; } while (0)
#define xfrm_audit_state_delete(x, r, a, s) do { ; } while (0)
+#define xfrm_audit_state_replay_overflow(x, s) do { ; } while (0)
+#define xfrm_audit_state_notfound_simple(s, f) do { ; } while (0)
+#define xfrm_audit_state_notfound(s, f, sp, sq) do { ; } while (0)
+#define xfrm_audit_state_icvfail(x, s, p)do { ; } while (0)
#endif /* CONFIG_AUDITSYSCALL */
static inline void xfrm_pol_hold(struct xfrm_policy *policy)
@@ -1045,7 +1056,8 @@ extern int xfrm_state_delete(struct xfrm_state *x);
extern int xfrm_state_flush(u8 proto, struct xfrm_audit *audit_info);
extern void xfrm_sad_getinfo(struct xfrmk_sadinfo *si);
extern void xfrm_spd_getinfo(struct xfrmk_spdinfo *si);
-extern int xfrm_replay_check(struct xfrm_state *x, __be32 seq);
+extern int xfrm_replay_check(struct xfrm_state *x,
+ struct sk_buff *skb, __be32 seq);
extern void xfrm_replay_advance(struct xfrm_state *x, __be32 seq);
extern void xfrm_replay_notify(struct xfrm_state *x, int event);
extern int xfrm_state_mtu(struct xfrm_state *x, int mtu);
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 5fc346d..8eb19c9 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -180,6 +180,7 @@ static int ah_input(struct xfrm_state *x, struct sk_buff
*skb)
err = -EINVAL;
if (memcmp(ahp-work_icv, auth_data, ahp-icv_trunc_len)) {
x-stats.integrity_failed++;
+ xfrm_audit_state_icvfail(x, skb, IPPROTO_AH);
goto out;
}
}
diff --git
[PATCH] XFRM: RFC4303 compliant auditing
NOTE: This really is an RFC patch, it compiles and boots but that is pretty
much all I can promise at this point. I'm posting this patch to gather
feedback from the audit crowd about the continued overloading of
the AUDIT_MAC_IPSEC_EVENT message type - continue to use it or create
a new audit message type? Of course any other comments people may have
are always welcome.
This patch adds a number of new IPsec audit events to meet the auditing
requirements of RFC4303. This includes audit hooks for the following events:
* Could not find a valid SA [sections 2.1, 3.4.2]
. xfrm_audit_state_notfound()
. xfrm_audit_state_notfound_simple()
* Sequence number overflow [section 3.3.3]
. xfrm_audit_state_replay_overflow()
* Replayed packet [section 3.4.3]
. xfrm_audit_state_replay()
* Integrity check failure [sections 3.4.4.1, 3.4.4.2]
. xfrm_audit_state_icvfail()
While RFC4304 deals only with ESP most of the changes in this patch apply to
IPsec in general, i.e. both AH and ESP. The one case, integrity check
failure, where ESP specific code had to be modified the same was done to the
AH code for the sake of consistency.
---
include/net/xfrm.h | 14
net/ipv4/ah4.c |1
net/ipv4/esp4.c|1
net/ipv4/xfrm4_input.c |6 +-
net/ipv6/ah6.c |1
net/ipv6/esp6.c|1
net/ipv6/xfrm6_input.c | 10 ++-
net/xfrm/xfrm_output.c |2 +
net/xfrm/xfrm_state.c | 155 ++--
9 files changed, 177 insertions(+), 14 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index c02e230..85ce8c1 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -492,11 +492,22 @@ extern void xfrm_audit_state_add(struct xfrm_state *x,
int result,
u32 auid, u32 secid);
extern void xfrm_audit_state_delete(struct xfrm_state *x, int result,
u32 auid, u32 secid);
+extern void xfrm_audit_state_replay_overflow(struct xfrm_state *x,
+struct sk_buff *skb);
+extern void xfrm_audit_state_notfound_simple(struct sk_buff *skb, u16 family);
+extern void xfrm_audit_state_notfound(struct sk_buff *skb, u16 family,
+ __be32 net_spi, __be32 net_seq);
+extern void xfrm_audit_state_icvfail(struct xfrm_state *x,
+struct sk_buff *skb, u8 proto);
#else
#define xfrm_audit_policy_add(x, r, a, s) do { ; } while (0)
#define xfrm_audit_policy_delete(x, r, a, s) do { ; } while (0)
#define xfrm_audit_state_add(x, r, a, s) do { ; } while (0)
#define xfrm_audit_state_delete(x, r, a, s)do { ; } while (0)
+#define xfrm_audit_state_replay_overflow(x, s) do { ; } while (0)
+#define xfrm_audit_state_notfound_simple(s, f) do { ; } while (0)
+#define xfrm_audit_state_notfound(s, f, sp, sq)do { ; } while (0)
+#define xfrm_audit_state_icvfail(x, s, p) do { ; } while (0)
#endif /* CONFIG_AUDITSYSCALL */
static inline void xfrm_pol_hold(struct xfrm_policy *policy)
@@ -1045,7 +1056,8 @@ extern int xfrm_state_delete(struct xfrm_state *x);
extern int xfrm_state_flush(u8 proto, struct xfrm_audit *audit_info);
extern void xfrm_sad_getinfo(struct xfrmk_sadinfo *si);
extern void xfrm_spd_getinfo(struct xfrmk_spdinfo *si);
-extern int xfrm_replay_check(struct xfrm_state *x, __be32 seq);
+extern int xfrm_replay_check(struct xfrm_state *x,
+struct sk_buff *skb, __be32 seq);
extern void xfrm_replay_advance(struct xfrm_state *x, __be32 seq);
extern void xfrm_replay_notify(struct xfrm_state *x, int event);
extern int xfrm_state_mtu(struct xfrm_state *x, int mtu);
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 5fc346d..8eb19c9 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -180,6 +180,7 @@ static int ah_input(struct xfrm_state *x, struct sk_buff
*skb)
err = -EINVAL;
if (memcmp(ahp-work_icv, auth_data, ahp-icv_trunc_len)) {
x-stats.integrity_failed++;
+ xfrm_audit_state_icvfail(x, skb, IPPROTO_AH);
goto out;
}
}
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index c31bccb..00ec285 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -183,6 +183,7 @@ static int esp_input(struct xfrm_state *x, struct sk_buff
*skb)
if (unlikely(memcmp(esp-auth.work_icv, sum, alen))) {
x-stats.integrity_failed++;
+ xfrm_audit_state_icvfail(x, skb, IPPROTO_ESP);
goto out;
}
}
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index 5e95c8a..6d7be5e 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -56,8 +56,10 @@ int xfrm4_rcv_encap(struct sk_buff *skb, int nexthdr, __be32
spi,
x =
Re: [PATCH] XFRM: RFC4303 compliant auditing
On Fri, 2007-12-07 at 16:06 -0500, Paul Moore wrote: On Friday 07 December 2007 3:52:31 pm Eric Paris wrote: On Fri, 2007-12-07 at 14:57 -0500, Paul Moore wrote: NOTE: This really is an RFC patch, it compiles and boots but that is pretty much all I can promise at this point. I'm posting this patch to gather feedback from the audit crowd about the continued overloading of the AUDIT_MAC_IPSEC_EVENT message type - continue to use it or create a new audit message type? Of course any other comments people may have are always welcome. I'm all for continuing to use it, but I feel like the op= strings should probably all get collected up in one place to ease maintenance in the future, might not matter but it's nice to be able to look only on place in the code to find all of the possible op= Agreed. I punted on doing anything here for two main reasons: 1. It makes sense to do this in the xfrm_audit_start() function which I couldn't use here without some overhaul ... 2. ... I didn't want to overhaul anything if I was going to end up using separate message types. If we decide to go with a single audit message type (kinda sounds like it) I'll fix this up in the next version. The one advantage to multiple messages is the ability to exclude and not audit certain things. How often will these extra messages actually pop out of a system? Enough that people would likely still care about some of them but decide they don't want others? I don't know this stuff, so tell me how often would any of these show up? Bingo, this is the whole reason why I was wondering about a different message type. Currently only SAD and SPD changes are audited and only because they effect the security labels that are assigned to packets as they are imported/exported out of the system (look at the LSPP requirements for auditing the import and export of data). These new audit messages apply to individual packets and/or a particular SA and have nothing to do with security labels, rather they indicate error conditions found during normal IPsec processing. It would be difficult to think of all of the particular cases where these error conditions but in general I would say that these audit messages should not be common. Yes, I agree. They should not happen often. Especially compared to LSPP requirements of auditing whenever SA or SPD entries were added or deleted, which are common events. The only reason for creating a separate audit message type for these packet/SA messages would be to meet a RFC requirement that states that the implementation MUST allow the administrator to enable and disable ESP auditing. Now, we can probably say we fulfill that requirement regardless, but more message types allow us greater granularity and flexibility ... Also, there is great possibility of additional messages. This is for RFC 4303, which is ESP. There are also audit messages listed for rfc 4301-IPsec architecture and rfc 4302-AH that may happen later. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
