Re: sshd transition points

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

On Wed, Feb 16, 2005 at 08:39:36AM -0500, Stephen Smalley wrote:
> On Wed, 2005-02-16 at 08:44, Luke Kenneth Casson Leighton wrote:
> >  out of curiosity: why?
> > 
> >  if it's specified in the policy, and there are permissions
> >  required for it to occur, what is the harm?
> 
> Because you have an application that has explicitly requested a context
> C1 but you are applying a different context C2 without its awareness. 

 i see what you mean: it's the fact that you are calling setcon()
 and it doesn't happen, something else happens

 it could be argued that the same thing happens with execve(), but
 i take the point that you're not actually calling something that
 says "set context NOW".

> Compare with file relabeling; we don't rewrite the context passed to
> setfilecon(3).  Or compare with setexeccon(3) - we don't rewrite the
> context passed to it.  That is different than applying a default context
> defined by policy when the application specified _no_ context for an
> execve or a file creation.
 
  okay, i get it.

> >  what rules must be placed in the policy such that
> >  security_compute_create will produce the desired results, for example:
> 
> It consults the type_transition rules in the policy.  It was named

 GREAT.

> >  if scon = "sshd_priv_t" and tcon = "user_t"
> >  [and tclass = SECCLASS_PROCESS?]
> > 
> >  and i want newcon to equal "sshd_priv_user_t" as a result of the call,
> > 
> >  what do i put in the policy to reflect this?
> 
> type_transition sshd_priv_t user_t:process sshd_priv_user_t;

 ah _ha_!

 thank you.


> But I'm still not clear on your usage, as these processes are not
> associated with a user.

 i believe one of my former messages (just 30mins ago) provides
 sufficient explanation.

 at the point at which do_authentication2() receives information
 about what username is to be used, i wish at THAT point to
 do a setcon() to sshd_priv_user_t, there and then.

 in order to stop any further unauthorised network traffic by
 that user.

 so i will put this:

	net_context 192.168.0.223 255.255.255.55 restricted_user_ip_t

 	allow restricted_user_1_ip_t:net_if sshd_priv_restricted_user_t 

 and consequently, if restricted_user isn't logging in from
 192.168.0.223, the sshd do_authentication2() function will be UNABLE
 to respond to any further authentication requests.

 i realise it's a bit dodgy, but it will do the job :)

 l.

-- 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--

--
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.