30 Apr, 2007

1 commit

  • On MIPv6 usage, XFRM sub policy is enabled.
    When main (IPsec) and sub (MIPv6) policy selectors have the same
    address set but different upper layer information (i.e. protocol
    number and its ports or type/code), multiple bundle should be created.
    However, currently we have issue to use the same bundle created for
    the first time with all flows covered by the case.

    It is useful for the bundle to have the upper layer information
    to be restructured correctly if it does not match with the flow.

    1. Bundle was created by two policies
    Selector from another policy is added to xfrm_dst.
    If the flow does not match the selector, it goes to slow path to
    restructure new bundle by single policy.

    2. Bundle was created by one policy
    Flow cache is added to xfrm_dst as originated one. If the flow does
    not match the cache, it goes to slow path to try searching another
    policy.

    Signed-off-by: Masahide NAKAMURA
    Signed-off-by: David S. Miller

    Masahide NAKAMURA
     

03 Dec, 2006

2 commits

  • Now that all protocols have been made aware of the mark
    field it can be moved out of the union thus simplyfing
    its usage.

    The config options in the IPv4/IPv6/DECnet subsystems
    to enable respectively disable mark based routing only
    obfuscate the code with ifdefs, the cost for the
    additional comparison in the flow key is insignificant,
    and most distributions have all these options enabled
    by default anyway. Therefore it makes sense to remove
    the config options and enable mark based routing by
    default.

    Signed-off-by: Thomas Graf
    Signed-off-by: David S. Miller

    Thomas Graf
     
  • Signed-off-by: Al Viro
    Signed-off-by: David S. Miller

    Al Viro
     

22 Oct, 2006

1 commit

  • As suggested by David, just kill off some unused fields in dnports to
    reduce sizef(struct flowi). If they come back, they should be moved to
    nl_u.dn_u in order not to enlarge again struct flowi

    [ Modified to really delete this stuff instead of using #if 0. -DaveM ]

    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

12 Oct, 2006

1 commit

  • 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 logic and propagating a false "ok" back up to
    xfrm_lookup(), which then allowed packets to pass as if they were not
    associated with an xfrm policy.

    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, because of an uncached lookup via
    flow_cache_lookup(), which would fail to resolve an xfrm policy because
    the SELinux policy is checked at that point via the resolver.

    However, retransmitted SYNACKs would then find a cached flow entry when
    calling into flow_cache_lookup() with a null xfrm policy, which is
    interpreted by xfrm_lookup() as the packet not having any associated
    policy and similarly to the first case, allowing it to pass without
    transformation.

    The solution presented here is to first ensure that errno values are
    correctly propagated all the way back up through the various call chains
    from security_xfrm_policy_lookup(), and handled correctly.

    Then, flow_cache_lookup() is modified, so that if the policy resolver
    fails (typically a permission denied via the security module), the flow
    cache entry is killed rather than having a null policy assigned (which
    indicates that the packet can pass freely). This also forces any future
    lookups for the same flow to consult the security module (e.g. SELinux)
    for current security policy (rather than, say, caching the error on the
    flow cache entry).

    Signed-off-by: James Morris

    James Morris
     

29 Sep, 2006

3 commits


23 Sep, 2006

4 commits


21 Mar, 2006

1 commit

  • The typedef for dn_address has been removed in favour of using __le16
    or __u16 directly as appropriate. All the DECnet header files are
    updated accordingly.

    The byte ordering of dn_eth2dn() and dn_dn2eth() are both changed
    since just about all their callers wanted network order rather than
    host order, so the conversion is now done in the functions themselves.

    Several missed endianess conversions have been picked up during the
    conversion process. The nh_gw field in struct dn_fib_info has been
    changed from a 32 bit field to 16 bits as it ought to be.

    One or two cases of using htons rather than dn_htons in the routing
    code have been found and fixed.

    There are still a few warnings to fix, but this patch deals with the
    important cases.

    Signed-off-by: Steven Whitehouse
    Signed-off-by: Patrick Caulfield
    Signed-off-by: David S. Miller

    Steven Whitehouse
     

04 Jan, 2006

1 commit

  • This patch series implements per packet access control via the
    extension of the Linux Security Modules (LSM) interface by hooks in
    the XFRM and pfkey subsystems that leverage IPSec security
    associations to label packets. Extensions to the SELinux LSM are
    included that leverage the patch for this purpose.

    This patch implements the changes necessary to the XFRM subsystem,
    pfkey interface, ipv4/ipv6, and xfrm_user interface to restrict a
    socket to use only authorized security associations (or no security
    association) to send/receive network packets.

    Patch purpose:

    The patch is designed to enable access control per packets based on
    the strongly authenticated IPSec security association. Such access
    controls augment the existing ones based on network interface and IP
    address. The former are very coarse-grained, and the latter can be
    spoofed. By using IPSec, the system can control access to remote
    hosts based on cryptographic keys generated using the IPSec mechanism.
    This enables access control on a per-machine basis or per-application
    if the remote machine is running the same mechanism and trusted to
    enforce the access control policy.

    Patch design approach:

    The overall approach is that policy (xfrm_policy) entries set by
    user-level programs (e.g., setkey for ipsec-tools) are extended with a
    security context that is used at policy selection time in the XFRM
    subsystem to restrict the sockets that can send/receive packets via
    security associations (xfrm_states) that are built from those
    policies.

    A presentation available at
    www.selinux-symposium.org/2005/presentations/session2/2-3-jaeger.pdf
    from the SELinux symposium describes the overall approach.

    Patch implementation details:

    On output, the policy retrieved (via xfrm_policy_lookup or
    xfrm_sk_policy_lookup) must be authorized for the security context of
    the socket and the same security context is required for resultant
    security association (retrieved or negotiated via racoon in
    ipsec-tools). This is enforced in xfrm_state_find.

    On input, the policy retrieved must also be authorized for the socket
    (at __xfrm_policy_check), and the security context of the policy must
    also match the security association being used.

    The patch has virtually no impact on packets that do not use IPSec.
    The existing Netfilter (outgoing) and LSM rcv_skb hooks are used as
    before.

    Also, if IPSec is used without security contexts, the impact is
    minimal. The LSM must allow such policies to be selected for the
    combination of socket and remote machine, but subsequent IPSec
    processing proceeds as in the original case.

    Testing:

    The pfkey interface is tested using the ipsec-tools. ipsec-tools have
    been modified (a separate ipsec-tools patch is available for version
    0.5) that supports assignment of xfrm_policy entries and security
    associations with security contexts via setkey and the negotiation
    using the security contexts via racoon.

    The xfrm_user interface is tested via ad hoc programs that set
    security contexts. These programs are also available from me, and
    contain programs for setting, getting, and deleting policy for testing
    this interface. Testing of sa functions was done by tracing kernel
    behavior.

    Signed-off-by: Trent Jaeger
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Trent Jaeger
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds