Messages in this thread | | | Subject | Re: [RFC][PATCH 1/7] fireflier LSM for labeling sockets based on its creator (owner) | From | Stephen Smalley <> | Date | Wed, 12 Apr 2006 15:11:52 -0400 |
| |
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/
| |