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

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2006-04-07 at 21:27 +0300, Török Edwin wrote:
> Auto-labeling logic. This is where the (individual&group) SIDs are generated, 
> and maintained.

> diff -uprN null/autolabel.c fireflier_lsm/autolabel.c
> --- /dev/null	1970-01-01 02:00:00.000000000 +0200
> +++ fireflier_lsm/autolabel.c	2006-04-07 17:43:48.000000000 +0300
> +/**
> + * internal_get_or_generate_sid - returns a SID that uniqueuly identifies 
> this devname+inode combination
> + * @devname - name of the mountpoint(device) the process's executable is on
> + * @inode - inode of the process's executable
> + * @unsafe - reason this process might be unsafe (ptrace,etc.)
> + */
> +static inline u32 internal_get_or_generate_sid(const char* devname,const 
> unsigned long inode,const char unsafe)
> +{
> +	u32 sid = FIREFLIER_SID_UNLABELED;
> +	const struct context context=
> +		{
> +			.inode = inode,
> +			.mnt_devname = unlikely(devname==NULL) ? empty_dev : devname,
> +			.groupmembers = 0,
> +			.unsafe = unsafe
> +		};
> +	sidtab_context_to_sid(&fireflier_sidtab,&context,&sid);
<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?

-- 
Stephen Smalley
National Security Agency