From: Eric Paris <eparis@redhat.com>
To: Paul Moore <paul.moore@hp.com>
Cc: James Morris <jmorris@namei.org>,
linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov,
netfilter-devel@vger.kernel.org, sds@tycho.nsa.gov,
jengelh@medozas.de, casey@schaufler-ca.com,
linux-security-module@vger.kernel.org, netfilter@vger.kernel.org,
mr.dash.four@googlemail.com
Subject: Re: [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid
Date: Mon, 27 Sep 2010 15:25:25 -0400 [thread overview]
Message-ID: <1285615525.2815.76.camel@localhost.localdomain> (raw)
In-Reply-To: <1285612156.4935.16.camel@sifl>
On Mon, 2010-09-27 at 14:29 -0400, Paul Moore wrote:
> On Mon, 2010-09-27 at 13:01 -0400, Eric Paris wrote:
> > On Mon, 2010-09-27 at 10:50 +1000, James Morris wrote:
> > > On Fri, 24 Sep 2010, Eric Paris wrote:
> >
> > > For the reasons above, I think the secctx string needs to be exported in
> > > addition to this rather than instead of.
> >
> > I won't argue, I don't agree with your reasoning, but I'm not opposed to
> > this result. We have 3 competing suggestions:
> >
> > Jan suggested we:
> > completely eliminate secmark from procfs+netlink and only export secctx
> > in netlink.
> >
> > Eric suggested we:
> > completely eliminate secmark from procfs+netlink and then export secctx
> > in procfs+netlink
> >
> > sounds like James suggested we:
> > continue to export meaningless and confusing secmark from procfs+netlink
> > and then export secctx in procfs+netlink as well.
> >
> > I'm going to implement James' idea and resend the patch series. Any
> > strong objections?
>
> I apologize for not getting a chance to look at these patches sooner.
> In general they look fine to me and my only real concern was addressed
> by Pablo already (breaking userspace due to #define changes).
>
> As far as exporting the 32bit secid/secmark to userspace, I think that
> is a mistake. James correctly points out that it does map to a LSM
> specific value, e.g. SELinux and Smack security labels, but I don't
> think he makes it clear that in the two LSMs that currently use secids
> the mapping between the secid and the secctx is not constant; the secids
> are transient values that will change with each boot in a manner that
> userspace can not predict. For this reason, I think exporting the
> secids is only going to cause users/admins grief, whereas exporting the
> associated secctx should be a much more stable value and is likely what
> the user/admin is expecting anyway.
So it sounds to me like Paul agrees with me that exporting the SELinux
sid as 'secmark=' was a bad idea. It's the whole reason this thread
started, someone wanted to be able to translate and use that field (and
instantly realized it was useless.)
I see it as having 3 options. lets assume was have a packet with
selinux sid=121 and selinux context=packet_t. We can
1) secmark=121 secctx=packet_t
This continues to send secmark like we do and people might continue to
be baffled by the 121.
2) secmark=1 secctx=packet_t
This sends a secmark field to userspace so if an application which
reads this exists (I doubt such an application actually exists in in the
real world) it will still get all of the information it got before but
noone will be baffled by what the number means. 1/0 is pretty obvious.
3) secctx=packet_t
Smallest easiest, what my patches actually do. Could theoretically
break some script that expected the field to be there, but any such
script is already broken since that field can be easily compiled
out......
James, if you are adamant about #1 I'll resend, otherwise I'm sticking
with #3.....
-Eric
next prev parent reply other threads:[~2010-09-27 19:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 20:45 [PATCH 1/6] secmark: do not return early if there was no error Eric Paris
2010-09-24 20:45 ` [PATCH 2/6] secmark: make secmark object handling generic Eric Paris
2010-09-25 8:39 ` Pablo Neira Ayuso
2010-09-27 16:47 ` Eric Paris
2010-09-24 20:45 ` [PATCH 3/6] secmark: export binary yes/no rather than kernel internal secid Eric Paris
2010-09-25 8:41 ` Pablo Neira Ayuso
2010-09-27 16:44 ` Eric Paris
2010-09-27 0:50 ` James Morris
2010-09-27 17:01 ` Eric Paris
2010-09-27 18:29 ` Paul Moore
2010-09-27 19:25 ` Eric Paris [this message]
2010-09-27 19:45 ` Paul Moore
2010-09-27 22:48 ` Pablo Neira Ayuso
2010-09-28 0:00 ` Jan Engelhardt
2010-09-28 8:45 ` Mr Dash Four
2010-09-27 23:45 ` James Morris
2010-09-28 12:32 ` Casey Schaufler
2010-09-24 20:45 ` [PATCH 4/6] security: secid_to_secctx returns len when data is NULL Eric Paris
2010-09-27 13:49 ` Casey Schaufler
2010-09-24 20:45 ` [PATCH 5/6] conntrack: export lsm context rather than internal secid via netlink Eric Paris
2010-09-24 21:08 ` Jan Engelhardt
2010-09-27 11:01 ` Pablo Neira Ayuso
2010-09-27 16:51 ` Eric Paris
2010-09-24 20:45 ` [PATCH 6/6] secmark: export secctx, drop secmark in procfs Eric Paris
2010-09-24 21:01 ` [PATCH 1/6] secmark: do not return early if there was no error Jan Engelhardt
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=1285615525.2815.76.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=jengelh@medozas.de \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mr.dash.four@googlemail.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
--cc=paul.moore@hp.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).