Linux-based access control

After the statement is not there iptables? Implementation of the principle diagram and the meaning of the parallel execution of the code to find the meaning of the balance and the artistic statement About the access control, the people have discussed a lot of programs, but do not think that a certain program is put Everything is everywhere, there is no such thing! RBAC is not suitable for the operating system of the macro protocol stack (UNIX, Linux, and so on... I may have reversed them in the previous article, ...), but this is not a member of every people. Know, including myself! In short, the packet must conform to the "fast, cool" style of the kernel protocol stack processing process, and can not lead to subsequent packet queuing, because different packets may belong to different "business logic". You can't assume that the business logic represented by the following packets will tolerate too much time before the packet is delayed. Everyone signs any protocol. For network devices, every packet is equal, if the advanced device is A data stream is equal. Remember, the device is born to forward data, and the destination of the data is not this device! All intermediate devices are TMD is a cloud, a so-called WEB acceleration server if it is not using the cache, then it is a scam! What can be faster with wire speed forwarding? No! No of CAO TMD! As long as there is a device between the Client and the Server, it adds latency to the TMD. Don't expect it to reduce latency unless God is constipated! Therefore, when designing intermediate devices, the goal is definitely not to reduce the delay fabulously, but “to be as fast as possible within the range you can control”, so the application processing method is not suitable. Don't expect to use any library to improve efficiency. Remember, the ultimate control is always in the hands of operators. Forever in the hands of network administrators who don't understand programming, just cut a network cable by anyone, and then TCP can't guarantee that you can send it gracefully. FIN, who can control the network can decide everything, the efficiency of the network is always more important than the efficiency of the end-to-end program! The purpose of this article is that you can ensure local processing as much as possible in one way, regardless of anything else. In the heavy rain on a Saturday, excited, inciting! I don't bother with the terminology in the mouth of the network, and I am not afraid of programming. For the network administrator and the programmer, maybe Otto von Bismarck can only say that it is unfortunate and angry. Although I don't understand OpenSSL, I am a programmer!

After the previous article "The Abstract Extension of Linux Routing Tables Applied to nf_conntrack" pointed out that Linux's IP routing mechanism can be used to implement access control lists, namely Linux ACLs. In that article, It just illustrates the feasibility of the implementation, but in the end, I used Linux's IP routing mechanism to save an info string for any nf_conntrack. This article describes in detail how to actually implement access control.

Isn't there an iptables? Why do you need to implement a new mechanism? Because: 1.iptables is based on Netfilter implementation, so only serial filtering can be implemented, that is, one-to-one matching; 2. Matching speed depends on the configuration order of iptables rules, and can not be uniformly optimized in the kernel; 3. I don't like iptables It is outdated in the multi-core era, although it is possible to develop a parallel version based on Netfilter, but it is too difficult. Therefore, in order to solve the above problem, I decided to implement an additional access control mechanism that does not rely on Netfilter. Obviously, one of my goals is that multiple cores can be scheduled during the matching process.

Implementation Principles Implementing a set of access control mechanisms for IP datagrams is not a simple matter. However, the most basic framework is very simple, that is, based on the source IP address and destination IP address of a packet. Decide what this packet can do. Of course, in addition to the IP address, any field in the IP data packet can participate in the matching, and even the fields of the TCP/UDP protocol header can participate in the matching, yes, but this article does not involve the complicated situation, those are It is easy to extend from the idea of ​​this article, so this article only uses the IP address as a matching element. As described in "The Abstract Extension of Linux Routing Tables Applied to nf_conntrack", an Action can be stored in a routing entry, but if another matching element target IP is introduced, the Action will no longer exist in the routing entry. The medium between the routing entries associated with the source IP address and the destination IP address indicates that all IP addresses included in the source routing entry can implement Action for all IP addresses included in the destination routing entry. Actions can be all possible actions such as pass, reject, address translation, and so on. If there is no Action associated between two routing items, the default Action is executed. It can be imagined that an Action must be two roles. On the one hand, it joins the Action Link List of the source routing item, and on the other hand it joins the Action Link List of the target routing item to associate the two. Borrowing the terminology of the RBAC permission model, I can think of the source IP address of a packet as a role, and the destination IP address of the packet can be regarded as a resource. Here is just borrowing the term, the real RBAC is better than me. More complicated. I will say later that my model looks at the way the kernel implements ACLs and algorithms, not the ACL model itself. The data structure is more straightforward than the illustration. Since each Action is linked to two linked lists at the same time, an Action named Xnode can be:

[plain] view plaincopyprint?01.struct nf_action_node { 02. //struct list_head list; //and Algorithm related, see note 1 03. struct hlist_node nf_dst; 04. struct hlist_node nf_src; 05. struct nf_fib_node *dst_node; //reverse pointer, algorithm optimization, see the search algorithm section 06. struct nf_fib_node *src_node; //reverse pointer , algorithm optimization, see the search algorithm section 07. int extra; 08. //int extra_len; 09. //char extra[0]; 10.}; struct nf_action_node { //struct list_head list; //related to the algorithm, see Comment 1 struct hlist_node nf_dst;