Re: [RFC][PATCH 1/7] fireflier LSM for labeling sockets based on its creator (owner)

[TÃrÃk Edwin]

On Wednesday 12 April 2006 22:11, Stephen Smalley wrote:
> On Fri, 2006-04-07 at 21:27 +0300, TÃrÃk Edwin wrote:
> <snip>
>
> > +u32 get_or_generate_sid(const struct file* execfile,const char unsafe)
> > +{
> > +	return
> > internal_get_or_generate_sid(execfile->f_vfsmnt->mnt_devname,execfile->f_
> >dentry->d_inode->i_ino,unsafe); +}
>
> (mnt_devname, ino) pair is not a suitable basis here.  If you truly
> cannot use inode extended attributes, then you might want to consider
> using file handles.  It would help to understand how the userspace
> component intends to use the supplied information, e.g. given some kind
> of identifier or attribute for the subjects that have access to the
> socket, what does the userspace component do with that identifier or
> attribute?
The userspace will read the attribute using getxattr, and see if the programs 
being accessing the socket are allowed by its rules, and will set the verdict 
on the packet.
The xattr of the socket inode will be a list of inodes of programs accessing 
the socket.

Lookup algorithm:
- find out socket inode from /proc/net/tcp|udp|tcp6|udp6
- search /proc/pid/fd/* for sockets with the proper inode (iterates through 
all pids)
- getxattr -> match rules

The /proc search is cached, so its only done on the 1st packet received, after 
that /proc/pidlast/fd/lastfd is stat-ed, and if the inode is still the same, 
no further searching is done. If not, the cache for that socket inode is 
invalidated.

I could have also dropped the cache, and done a full /proc lookup to find out 
which processes have access to a socket, but I think you'll agree that this 
would have had a huge impact on performance.


Alternatively an iptables module can be used that matches based on security 
context (if the userspace /proc search would be too slow on a high-load 
connection for example).

P.S.: The userspace part that reads xattr isn't implemented yet.

Cheers,
Edwin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/