Re: identity

[Joshua Brindle <jbrindle@snu.edu>]

Joseph Pingenot wrote:

> From Russell Coker on Monday, 23 February, 2004:
> 
>>On Mon, 23 Feb 2004 17:02, Joseph Pingenot <trelane@digitasaru.net> wrote:
>>
>>>Sounds like a good idea.  One question:
>>>Could you also record a signature of the data?  This would help distinguish
>>>       processes who aren't supposed to be letting users on the system
>>>       (since they'd not have a valid signature).  That'd potentially
>>>       be able to plug a standard usage of rooted systems: leave open a
>>>       port to the outside world to log in from.
>>
>>That wouldn't work.
>>If a regular user shell process running as user_u:user_r:user_t can access the 
>>network then it can also launch other shells.  There is no way of stopping 
>>this.
>>How do you distinguish a copy of bash launched as a shell for an interactive 
>>session from an interpreter for a shell script?
>>How do you distinguish programs such as "script" from a wrapper for a UDP 
>>based terminal system?
> 
> 
> Heh.  That's what I get for posting after just a moment's thought, right
>   before I hit the hay.  :)
> Excellent points.  I had originally been thinking that the info would
>   be inherited by children (as would be logical), but it'd not actually
>   prevent any such thing.  Dang.
> Hmm.  Thinking about it again, maybe one could add a 'tainted' flag to
>   a process that gets set when it listens to a socket?  Servers would
>   be accompanied by a signature that verifies the integrity of the binary
>   and are then not tainted on socket opening *if* they match?
> Eh.  It seems like a good thing to eventually work towards.  :)
> 

Mine are inherited by children, i see what you are asking for but this 
seems far outside of the scope of selinux (not that mine are within 
scope per se. I don't like the idea of sticking this into userland 
becuase that requires modifying all login apps wheras mine is generic 
and works with anything that creates a socket. Another problem I see 
with this is, there is nothing that keeps a malicious userland app from 
reproducing that 'signature' so it's not incredibly useful.

I've looked at the selinux code for implementing something like this 
without reaching outside of selinux/lsm and I just don't see any way for 
it to be done since the sid is created in selinux and used to resolve to 
a string context (including identity). It would have been ideal to have 
an identity struct that arbitrary data could be added to but this isn't 
done in selinux.

Furthermore, I just did this patch because it's far easier to track down 
   the culprit of a rogue process if the ip information is available in 
addition to the context and UID.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.