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
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <pmoore@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: linux-security-module@vger.kernel.org, linux-audit@redhat.com,
selinux@tycho.nsa.gov,
Paul Osmialowski <p.osmialowsk@samsung.com>
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
next prev parent reply other threads:[~2015-10-09 20:29 UTC|newest]
Thread overview: 30+ 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-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-19 22:29 ` Paul Moore
2015-10-20 20:41 ` Stephen Smalley
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:25 ` Steve Grubb
2015-10-09 16:40 ` Stephen Smalley
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-08 16:55 ` Paul Moore
2015-10-09 15:05 ` Stephen Smalley
2015-10-09 15:39 ` Paul Moore
2015-10-09 15:39 ` Paul Moore
2015-10-09 20:17 ` Stephen Smalley
2015-10-09 20:17 ` Stephen Smalley
2015-10-09 20:29 ` Paul Moore [this message]
2015-10-09 20:29 ` Paul Moore
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.