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

Török Edwin
2006-04-14T20:03:00Z

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