Older blog entries for huagang (starting at number 16)

The new version of LIDS 2.2 will remove the origninal xattr support, but will use the inode labeling concept to enhance the acl search/labeling performance.

The new version compatible with old version of LIDS, the only difference is after all the lidsconf acl, user need to do a

#lidsconf -C

to compile the acl into a binary file..kernel will read this binary file to parse it. The benifit is now kernel only need to read one file and will not do all the atoi() etc..and will make it more secure.

The new version make the lidsconf do more job and let the kernel do less job. Now not only the process have the object list (a simple one, only contain a sid and oid and a inherit ) and the object also have a list showing which program have what kind of permisson on it. In this way, process will do all the inherit merging staff and checking its acl with the object inode's peromssion bits.

Another enhancement is when fetching an inodes' acl, if it is not attached, will go to check its parent dir until found an acl. once found, the acl will attached to it and all the parent directory. In this way, the next time, when the same inode being accessed, it will get the acl right away, even if the file is not the same, but in the same directory, it will only go up once to its direct parent and get the inode. This way will accelate the performance when doing acl comparision/checking.

I was thinking of making a new directory under the lidstools to include the most useful acls. For example, ACLs for apache, Acls for bind etc. I guess that will help the first-time user to make it easier to pick it up.

After the version release, there some post on the mailing list disappoited about some of features remove, especially the time support. I explained to one of the post.

Comparing the more memory needed , more function to support it with the actually usefulness of the function, I decided not to support this feature. When you have the time support, you can specify at what time range the subject(program) can access the object(file), without it, the program can always can write to the object(file), from the security point of view, the time support do not increase the security bar, because the attacker can launch the attack at the specific time or just try every one min.

Finally!! After a few test on other machine. And in the last minitus adding netlink support to make "iproute2" can be controled by capability(a bug report on lids-user mailing list).

Check it out on http://www.lids.org

More QA testing on the whole package again and enhance a few thing. One nice feature is to add the object filename in xattr, which will let the user know which file has the permission on which object file.

Fedora Core I

Install a Fedora Core I and configure it to use LIDS 2.2..found one minor problem is the ACL setting on sshd can not be automatically attaching to the sshd which is still running in the system. I have to do a "+RELOAD_CONF" to make it effetive. ;_((.. but anyway, It should not make user confuse since we still have to do it for now.

release it today ??

let's see, if I find any problem or not..I already finished a draft for the new features and the website content changed. Hope I can make it today.

It is really a good day today.

Moving those #ifdef to a include/header file. and split up some of overly long functions. Make some function to be 'static'.

The only thing lefe is some document about the new xattr support. after that, the new version will be out!

Since kernel has the cryptoapi support in the kernel( see crypto/ directory under the kernel source), there is no need for LIDS still putting RMD160 in the kernel. So We switch to use one of the crypto api..In order to make current LIDS user do not feel the underground change, a new method is used to replace the rmd160 by sha256. The kernel code has been ported to the userspace and be used by lidsadm/lidsconf to read/generate the password without the kernel. And in the LIDS kernel part, using the cryptoapi, it is very easy to cryto the password and do the comparsion. The code do not change a lot, just a few line added and removed. The only problem I run into is the over large memset a buffer which cause some memory to be 0..:-(( any way, now everything seem fine.

My todo list lefe a code clean and then we can release this new version.!!

I am pretty happy now. Thanks to GPL, I can check a lot of open source code before I write my own..that really help.

Although I thought maybe I should release it before the state support, anyway, after I finished the lidstools part support, and the kernel part code seems easy to do. The only problem let me stop for a while is the a new file/inode created in a privilege directory. Before that, it is easy, just copy what the current dir's inode-i_security, but now, the default acl and current state's acl need to copy into the new one.

One problem I always think is the dynamic inode, which has the same filename. for example, /etc/shadow will be change the inode after a new user has been added/detected. for now, it will just be the same as the "/etc/", can not be hidden any longer.

inode,dentry, file, dir.

Wish the world do not share and lock go way.

Rusty Russell's Unreliable Guide To Locking give a very good introductionto the locking in linux kernel. The most important thing is to indentify the critical region and then apply lock on them.

here are two main types of kernel locks. The fundamental type is the spinlock (include/asm/spinlock.h), which is a very simple single-holder lock: if you can't get the spinlock, you keep trying (spinning) until you can. Spinlocks are very small and fast, and can be used anywhere. The second type is a semaphore (include/asm/semaphore.h): it can have more than one holder at any time (the number decided at initialization time), although it is most commonly used as a single-holder lock (a mutex). If you can't get a semaphore, your task will put itself on the queue, and be woken up when the semaphore is released. This means the CPU will do something else while you are waiting, but there are many cases when you simply can't sleep (see Chapter 9), and so have to use a spinlock instead.

Sleep sleep sleep Zzzzzzzz

Yeah..if you can not sleep, you can not use semaphore! If you hold a lock, you can not sleep!! That is the rule. You can not take something back home and sleep, you need to take care someone else who still running and need your unlock to get some thing.

LIDS with the lock and sleep

I fight with the sleep while hold a lock for a few times. This time, I learn to not using sleepable function like kmalloc(GFP_KERNEL), getxattr, setxattr etc while within a lock. Instead, just put what you want to process into a list and then unlock it and process the list one by one to get what you want to done.
Locking? yeah..task->security need to be lock each time you set it. inode->i_security need spin_lock(&i_lock) as well. And for each subject_acl, yes, each task_acl has a t_lock and each inode_acl got a i_lock too. Go bless this lock! I still remember year 2000, I forget to init a spin_lock and a lot of problems coming out without any sense..:-((

After almost 2 weeks hard working..XATTR/EA is working with LIDS now. the supporting lidstools also has the support to "-A" , "-D"..but the code still need to clean up before release.

With XATTR support, LIDS will have better performance vs old way. Because the ACL now store in inode->xattr and the checking will not need a big loop to get its own ACL.

Kernel hacking/programming is more difficult than user space programming, is because you need to know how the kernel implement first. But good thing is, the source is there, you can always check it by yourself.

Thanks to Chris Wright of ODSL for the support.