Re: [PATCH 3/6] secmark: export binary yes/no rather than kernelinternal secid

[Eric Paris]

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

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