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
communications
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
scattered
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
else
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
www.sourceforge.net/projects/disec.
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.
cheers,
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
>*optptr,
> 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
>option
> * parameter.
>
>thanx!
> yuan
>
>_______________________________________________
>linux-security-module mailing list
>linux-security-moduleat_private
>http://mail.wirex.com/mailman/listinfo/linux-security-module
>
>
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Sep 04 2003 - 10:46:30 PDT