Re: how to get ip options in lsm hook function -- security_socket_recvmsg?

From: Makan Pourzandi (Makan.Pourzandiat_private)
Date: Thu Sep 04 2003 - 10:50:07 PDT

  • Next message: Greg KH: "Re: [PATCH] (improved) LSM root_plug fixup"

      Yuan ChunYang wrote:
    >hi,now i can add labels in ip options in security_socket_sendmsg.
    >But can i do get ip options in security_socket_recvmsg ? 
    Hi Yuan,
    Could you give mode details about the general context of your
    test/development environment?
     From what I understood, I believe that we had the same problem in DSI
    project. Therefore, here's my analysis of the problem. I hope that
    this could be of some use to you.
    We use IP options to carry security related info for access control 
    inside the
    cluster.  However, we restricted the scope of their use to the 
    between nodes inside the cluster (this can be extended to the member 
    nodes of a
    Grid). We don't want to use the ip options for handling communications 
    with external nodes
    to the cluster even if we could discard the possibility of tempering
    with ip options by using network security protocls like ipsec. The
    main reason behind this is that external nodes represent clients for
    us, and often we cannot mess up with the client's environment (not
    accepted by the clients or in the case of the web server alike
    applications, we have to accept clients without any assumption
    regarding their environment); the second reason is that we remarked
    empirically that in the Internet some edge router (or core routers
    ???)  modify/reset the ip options. I checked the rfc for ip protocol
    and actually it turned out that nothing in the rfc states that the
    routers must not modify the ip options. Anyway, by experience, we
    remarked that the ip options most often are set to null when your ip
    packets have to "travel" through the Internet. My hypothesis is that
    this is done by edge routers (or core routers?, even some "commercial"
    switches  drop ip packets with ip options).  This is rather an empirical 
    result and I would be more than
    happy to have a better explanation.
    All that is to say that I wonder if this is a good idea of using ip
    options to carry security related info when your ip packets have to
    "travel" through the Internet. Here I'm optimistic to suppose that you
    can use a network protocol like ipsec with support for ip options
    in order to provide integrity protection
    of your packets ;-). we had to patch frees/wan to make it support ip
    options and ssh doesn't support ip options as far as I remember, but
    that could change! Well you could always go with tunneling but this is
    not a valid solution if you have many clients from different networks 
    around the world.
    Anyway, back to the subject, therefore we chose to use the ip options
    only for inter-cluster access control purposes and tackle the
    extra-cluster connection security otherwise, i.e. security protocols:
    ssl, ipsec or ipfilter,... you choose.
    Then in our DSI kernel module, we implemented the following algo:
    if ( ip packet comes from the inside of the cluster) then
       if not ip options then
          drop ip packet. // not access control info
        extract ip options
        interpret security info in it
        make decision according to security rules: drop ? accept
    else // ip packet coming from outside
         the security is handled outside of the cluster 
    We implemented this approach inside DSI for the nodes of the cluster
    and never had any problem with ip options i.e. ip options null, 
    attention: as
    long as your ip packets don't "travel" through the Internet and your
    switches are correctly configured (not dropping ip packets with ip
    options). I believe that this hypothesis makes sense for us as we
    don't want to expose our cluster internals to the Internet.
    You've the source code available from
    BTW, dsi-0.4 runs on 2.5.66 and has our first experimental version of
    digital signature validation for binaries inside the kernel. Therefore
    we didn't update the documentation. We're in the middle of making a
    seperate package from dsi for signature verification and when we're
    done with it I'll send an email to lsm mailing list. Anyway, that's to
    say that you rather use dsi-0.3 which runs on 2.4.17. The
    functionality is the same regarding ip options.
    Well, I remember that in another discussion in dsi project mailing
    list, you pointed out that we only use ip options for socket
    connections and not for all ip packets. I still believe that you've a
    valid point, but as I need to know more about the details of the Linux
    kernel, I put that in DSI to do list and want to do some extensive
    testing on it before going there.
    Makan Pourzandi
    >i try it in security_socket_recvmsg :
    >	struct sock *sk = sock->sk;
    >	struct inet_opt *inet=inet_sk(sk);
    >	struct ip_options *opt = NULL;
    >	opt = inet->opt;
    >	saddr_skb=inet->saddr;
    >	if ( !opt ){
    >		printk("daddr : %x\n",inet->daddr);
    >		printk("dport : %d\n",inet->dport);
    >		printk("source ip: %x\n",saddr_skb);
    >		printk("sport : %d\n",inet->sport);
    >		printk("inet->opt : %d\n",inet->opt);
    >		printk (KERN_INFO "opt == NULL in smos_socket_recvmsg! \n");
    >		return 0; // 22, Invalid argument
    >	} else        
    >    		return secopt_socket_check_ip_options((char *)opt);
    >BUT opt=NULL. 
    >another question is in security_ip_decode_options function :
    > static int security_ip_decode_options (struct sk_buff *skb, const char
    >				    unsigned char **pp_ptr) 
    >i can not know the meaning of pp_ptr.can somebody explain it clearly ?
    >it's explained in lsm as:
    > * pp_ptr contains the 
    > * parameter problem pointer. Returns 0 on success. A non-zero return
    >value will 
    > * cause an ICMP parameter problem message to be generated and
    >transmitted to the 
    > * sender. The pp_ptr parameter may be used to point to the offending
    > * parameter. 
    >                                                                            							yuan
    >linux-security-module mailing list
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Sep 04 2003 - 10:46:30 PDT