Re: Why "id -Z" get the current process security context but says "of the current user" in help?

[Casey Schaufler]

On 1/23/2014 4:27 AM, Jarkko Sakkinen wrote:
> Hi
>
> On Thu, Jan 16, 2014 at 12:07:02PM +0000, Pádraig Brady wrote:
>> On 01/16/2014 06:24 AM, Jarkko Sakkinen wrote:
>>> Hi
>>>
>>> On Thu, Jan 16, 2014 at 02:16:28AM +0000, Pádraig Brady wrote:
>>>> So I suppose we might change the --help docs etc. to say
>>>> _process_ rather than _user_.  Is SMACK64EXEC a common
>>>> label to have set on the id executable? Jarkko I don't suppose
>>>> there is any way to avoid that?
>>> I don't see any reason why anyone would set SMACK64EXEC for 'id'. There's
>>> no realistic use case to do that.
>> OK it's an edge case so we can set the docs accordingly.
>> BTW I notice SELinux' getprevcon() which is the same as getcon()
>> but gets the context before the last exec.

SELinux process contexts change for any number of policy defined
reasons. With SELinux it is not a safe bet that id will run with the
same context as the shell that invokes it. What's more, one would
have to be an expert in SELinux policy and very familiar with the
policy on the system in question to know whether a call to getcon()
will return the same value in the shell and in id. This is why SELinux
has getprevcon() and /proc/self/attr/prev.

>> If SMACK had an equivalent would that be more appropriate to use here?
> SMACK does not provide anything similar in its kernel interface.

Smack process labels (or contexts, if you prefer SELinux terminology)
rarely change. They can change on exec(), but that requires that an
attribute (SMACK64EXEC) be associated with the file. Anyone who can
execute the program can look to see if that attribute is set. Privilege
is required to set that attribute. Only a badly miss-configured system
would have the SMACK64EXEC attribute set on the id binary, and that
would be easy to detect.