From: Paul Moore <pmoore@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Paul Osmialowski <p.osmialowsk@samsung.com>,
linux-security-module@vger.kernel.org, linux-audit@redhat.com,
selinux@tycho.nsa.gov
Subject: Re: [RFC PATCH v3 5/5] selinux: introduce kdbus access controls
Date: Fri, 09 Oct 2015 16:29:27 -0400 [thread overview]
Message-ID: <6100682.R2RFojQALf@sifl> (raw)
In-Reply-To: <561820CD.4050401@tycho.nsa.gov>
On Friday, October 09, 2015 04:17:17 PM Stephen Smalley wrote:
> On 10/09/2015 11:39 AM, Paul Moore wrote:
> > On Friday, October 09, 2015 11:05:58 AM Stephen Smalley wrote:
> >> On 10/07/2015 07:08 PM, Paul Moore wrote:
> >>> +static int selinux_kdbus_init_inode(struct inode *inode,
> >>> + const struct cred *creds)
> >>> +{
> >>> + struct inode_security_struct *isec = inode->i_security;
> >>> + u32 sid = cred_sid(creds);
> >>> +
> >>> + /* XXX - this is very simple, e.g. no transitions, no special object
> >>> + * class, etc. since this inode is basically an IPC socket ...
> >>> + * however, is this too simple? do we want transitions? if
we
> >>> + * do, we should do the transition in kdbus_node_init() and
not
> >>> + * here so that endpoint is labeled correctly and not just
this
> >>> + * inode */
> >>> +
> >>> + isec->inode = inode;
> >>> + isec->task_sid = sid;
> >>> + isec->sid = sid;
> >>> + isec->sclass = SECCLASS_FILE;
> >>> + isec->initialized = 1;
> >>
> >> These are used for files exposed in the filesystem namespace, unlike
> >> sockets (sockfs can't be mounted by userspace, and the socket objects
> >> themselves have their own class, so there is no ambiguity). Currently
> >> the only such files that are labeled with the same SID as the associated
> >> task are /proc files. So if we label the kdbusfs files with the same
> >> SID, then you can't allow read/write to kdbusfs nodes owned by another
> >> task without also exposing its /proc/pid files in the same manner.
> >> Doubt we want that. Probably should compute a transition from the task
> >> SID and the kdbusfs SID.
> >
> > Okay, that was one of my main concerns; your suggestion makes sense to me.
> >
> > I'm also thinking that is we do a file transition using the task label and
> > the kdbusfs superblock label we should limit it to just the inode label
> > and not the kdbus endpoint as I suggested in the comment above (the bit
> > about kdbus_node_init()), yes?
>
> Yes, it only needs to be done for the inode, not the endpoint.
> Analogy with sockets: Can I write to the socket file (kdbus file) bound
> to the socket (endpoint)? Can I connectto/sendto the socket (endpoint)?
Yep.
I'll make these changes and work to get another draft out next week.
--
paul moore
security @ redhat
prev parent reply other threads:[~2015-10-09 20:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 23:08 [RFC PATCH v3 0/5] kdbus LSM/SELinux hooks Paul Moore
2015-10-07 23:08 ` [RFC PATCH v3 1/5] kdbus: add creator credentials to the endpoints Paul Moore
2015-10-09 14:31 ` Stephen Smalley
2015-10-09 14:57 ` Paul Moore
2015-10-07 23:08 ` [RFC PATCH v3 2/5] lsm: introduce hooks for kdbus Paul Moore
2015-10-09 14:56 ` Stephen Smalley
2015-10-19 22:29 ` Paul Moore
2015-10-20 20:41 ` Stephen Smalley
2015-10-29 20:38 ` Paul Moore
2015-10-07 23:08 ` [RFC PATCH v3 3/5] lsm: add support for auditing kdbus service names Paul Moore
2015-10-09 14:57 ` Stephen Smalley
2015-10-09 16:25 ` Steve Grubb
2015-10-09 16:40 ` Stephen Smalley
2015-10-07 23:08 ` [RFC PATCH v3 4/5] selinux: introduce kdbus names into the policy Paul Moore
2015-10-09 16:38 ` Stephen Smalley
2015-10-07 23:08 ` [RFC PATCH v3 5/5] selinux: introduce kdbus access controls Paul Moore
2015-10-08 16:55 ` Paul Moore
2015-10-09 15:05 ` Stephen Smalley
2015-10-09 15:39 ` Paul Moore
2015-10-09 20:17 ` Stephen Smalley
2015-10-09 20:29 ` Paul Moore [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6100682.R2RFojQALf@sifl \
--to=pmoore@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=p.osmialowsk@samsung.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).