Re: How to attach some config info permanently to a object?

Previous message: Stephen D. Smalley: "[patch] Use CONFIG_SECURITY for clone_sk/clone_tcp_sk definition"
In reply to: ЖЋЗН ѓЛЮ: "How to attach some config info permanently to a object?"
Next in thread: Chris Wright: "Re: How to attach some config info permanently to a object?"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Valdis.Kletnieksat_private

On Thu, 23 Jan 2003 17:23:12 +0800, =?gb2312?B?tqu3vSDzu87E?= <phanixat_private>  said:
>
>  The module's config file is /etc/mec.conf. In the config file, for 
> example:
> 
>  /bin/bash
>  !{
>   /bin/ping
>  }
>  #This means a /bin/bash process can execute anything but /bin/ping.

There's a subtle issue here...

Did you want to restrict access to the *PATH* /bin/ping, or to the *object*
referred to (the binary described by that inode)?  The difference becomes
important if the user can partly subvert the security model (for instance,
if he finds a way to rename /bin/ping to an allowed name, or to create a
new hardlink to the same inode, or any number of other games such as mounting
over a directory, etc).

> *** What if any other module uses task's void *security pointer and set it to 
>     some other value?( Do I realy need to maintain a hashlist of pid and confinfo
>     in the module? )

This is a well known issue, generally called "don't stack security modules that
aren't willing to cooperate with each other".  If you have two modules that
each want to use the *security pointer and don't know about each other, you
will have nothing but headache.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech