lkml.org 
[lkml]   [2006]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 1/7] fireflier LSM for labeling sockets based on its creator (owner)
From
Date
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

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

\
 
 \ /
  Last update: 2006-04-12 21:09    [W:0.153 / U:1.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site