sshd transition points

sshd transition points

[Luke Kenneth Casson Leighton]

hi,

i'm just in the process of setting up a rather paranoid selinux
environment involving sshd, on a Redhat FC3 system.

the execution of ordinary shells (/bin/bash) is banned - or at
least must be restricted / tracked by selinux.

i am running the sftp subsystem.

therein lies part of the problem - sshd appears to be running
/bin/bash for a user - in the sshd_t domain - as part of the
process of firing up /usr/libexec/ssh/sftp-server.

which is a bit weird and annoying, because what i _wanted_ to do
was to associate a user with a net_context, such that only
a particular user may sftp in from a certain IP address.

... and that's not possible, because by the time sftp-server is
being run, there's a disconnect: sftp-server is in the correct
domain but it only has a unix-domain-socket to contact a forked
sshd, which has the TCP connection open but is still running
in the domain sshd_t.

so basically, my question boils down to this:

* _should_ sshd, after a fork, be still running in sshd_t?

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.

Adding libseuser functionality to libselinux?

[Daniel J Walsh]

Thoughts on moving some of the functions available in setools into 
libselinux.

Basically I want to add the ability to addroles via the adduser command  
(shadow-utils) and thus
make dealing with roles easier in OS.  The problem is that I don't want 
to require setools  in
order to get this functionality (libseuser).   

I need the ability to get the roles that are available via the currently 
running policy and to manipulate
the users defined in the local.users file.  I then need to have 
genpolusers type functions to allow me
to change the running policy.  We don't need the functionality that 
deals with policy-sources.

What do you think of moving these functions into libselinux?

Dan

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

Re: Adding libseuser functionality to libselinux?

[Stephen Smalley]

On Tue, 2005-02-15 at 11:22, Daniel J Walsh wrote:
> Thoughts on moving some of the functions available in setools into 
> libselinux.
> 
> Basically I want to add the ability to addroles via the adduser command  
> (shadow-utils) and thus
> make dealing with roles easier in OS.  The problem is that I don't want 
> to require setools  in
> order to get this functionality (libseuser).   
> 
> I need the ability to get the roles that are available via the currently 
> running policy and to manipulate
> the users defined in the local.users file.  I then need to have 
> genpolusers type functions to allow me
> to change the running policy.  We don't need the functionality that 
> deals with policy-sources.
> 
> What do you think of moving these functions into libselinux?

I think you want them in libsepol, not libselinux.  The former is for
binary policy manipulation (which can still deal with the "active"
policy file that happesn to be presently loaded, as long as said file
still exists on the filesystem and you can reliably find it) and can be
used even on non-SELinux systems (an important property for building and
analyzing policies).  The latter is only for security-aware applications
running on a SELinux kernel.

I do plan to look into migrating genpolusers functionality into
libsepol, as I formerly did for genpolbools, to allow load_policy and
init to generate the users database based on local customizations at
load time, just as they currently set the booleans based on local
customizations at load time.  I'm not sure what you want from libseuser;
you can certainly implement functions in libsepol that extract the set
of roles for a user and manipulate it.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: Adding libseuser functionality to libselinux?

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-02-15 at 11:22, Daniel J Walsh wrote:
>  
>
>>Thoughts on moving some of the functions available in setools into 
>>libselinux.
>>
>>Basically I want to add the ability to addroles via the adduser command  
>>(shadow-utils) and thus
>>make dealing with roles easier in OS.  The problem is that I don't want 
>>to require setools  in
>>order to get this functionality (libseuser).   
>>
>>I need the ability to get the roles that are available via the currently 
>>running policy and to manipulate
>>the users defined in the local.users file.  I then need to have 
>>genpolusers type functions to allow me
>>to change the running policy.  We don't need the functionality that 
>>deals with policy-sources.
>>
>>What do you think of moving these functions into libselinux?
>>    
>>
>
>I think you want them in libsepol, not libselinux.  The former is for
>binary policy manipulation (which can still deal with the "active"
>policy file that happesn to be presently loaded, as long as said file
>still exists on the filesystem and you can reliably find it) and can be
>used even on non-SELinux systems (an important property for building and
>analyzing policies).  The latter is only for security-aware applications
>running on a SELinux kernel.
>
>I do plan to look into migrating genpolusers functionality into
>libsepol, as I formerly did for genpolbools, to allow load_policy and
>init to generate the users database based on local customizations at
>load time, just as they currently set the booleans based on local
>customizations at load time.  I'm not sure what you want from libseuser;
>you can certainly implement functions in libsepol that extract the set
>of roles for a user and manipulate it.
>
>  
>
Yes that makes more sense. 
I need the ability to read/add/modify/delete a user record in the 
local.users file.

Dan

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

Re: sshd transition points

[Stephen Smalley]

On Tue, 2005-02-15 at 10:53, Luke Kenneth Casson Leighton wrote:
> so basically, my question boils down to this:
> 
> * _should_ sshd, after a fork, be still running in sshd_t?

I'm not sure I follow your posting.  Transitions normally only occur
upon execve.  sshd should transition upon executing the shell, of
course.  IIRC, there is an issue with regard to SELinux not being able
to fully leverage the privilege separation support in sshd since that
requires dynamic transitions.  Of course, since dynamic transition
support now exists, someone could look into changing sshd to use it for
finer-grained privilege bracketing.
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Tue, Feb 15, 2005 at 01:14:53PM -0500, Stephen Smalley wrote:
> On Tue, 2005-02-15 at 10:53, Luke Kenneth Casson Leighton wrote:
> > so basically, my question boils down to this:
> > 
> > * _should_ sshd, after a fork, be still running in sshd_t?
> 
> I'm not sure I follow your posting.  

 see example ps -axZ below as to the bit i have concerns about
 (process 5001 in the example).

> Transitions normally only occur
> upon execve.  sshd should transition upon executing the shell, of
> course.  

 and then that shell does a further execve of the sftp-server?

> IIRC, there is an issue with regard to SELinux not being able
> to fully leverage the privilege separation support in sshd since that
> requires dynamic transitions.  Of course, since dynamic transition
> support now exists, someone could look into changing sshd to use it for
> finer-grained privilege bracketing.
  
  that would provide me with a solution 6 months down the line
  [when FC4 or FC5 is released] and i am therefore planning ahead:
  the present solution is a bit iffy.

  i'll try to explain a bit better.

  when i run ps -axZ, i get this:

  2000 sshd_t	                /usr/sbin/sshd
  5001 sshd_t	                /usr/sbin/sshd
  5004 restricted_sftp_user_t	/usr/libexec/ssh/sftp-server

  now, when i do a lsof -p 5001, it shows that that sshd, which is
  still running in sshd_t, has the open TCP connection.

  lsof -p 5004 shows sftp-server has only a couple of sockets open.

  what the _heck_ is that sshd doing still running as root, or
  more specifically, what's it doing still running under sshd_t?

  the process 5004 would be where the execve() took place, so
  it at least went to restricted_user_t, such that this works:

	  domain_auto_trans(restricted_user_t, sftp_server_exec_t,
			    restricted_sftp_user_t)

 so there are at least two forks() - one to handle the incoming
 connection and one to handle the user context (and a socket
 of some type is set up between the two to "disconnect" the
 user shell from the TCP socket).

 then, the shell is execve()'d in the last of these fork()s, and then
 sftp-server is execve()'d in that.

 unfortunately, then, as things stand, it's not possible to
 associate a security context with the "initial" fork - the
 one that holds the TCP connection.

 ... and what you are saying is that now that dynamic transitions
 are possible, it might be doable?

 okay.

 if nothing else, this has been an opportunity for me to get my
 head round the issues, and to understand what's going on.

 i'll put in my projects "TODO" list something for the client to
 fund if they want to improve useability.

 l.


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

Re: sshd transition points

[Stephen Smalley]

On Tue, 2005-02-15 at 14:16, Luke Kenneth Casson Leighton wrote:
>  and then that shell does a further execve of the sftp-server?

I think that sshd runs the subsystem via a shell, e.g. $SHELL -c
sftp-server.  Hence, sshd will set the exec context prior to invoking
the shell based on the default context for the user, so that the shell
will run in the user's domain, and then there may or may not be another
transition (subject to policy) upon execution of sftp-server by the
shell.

>   what the _heck_ is that sshd doing still running as root, or
>   more specifically, what's it doing still running under sshd_t?

Isn't this the normal privilege separation support in sshd, with the
parent being the privileged monitor and the child as the user
unprivileged process?  See
http://www.citi.umich.edu/u/provos/ssh/privsep.html

>  unfortunately, then, as things stand, it's not possible to
>  associate a security context with the "initial" fork - the
>  one that holds the TCP connection.
> 
>  ... and what you are saying is that now that dynamic transitions
>  are possible, it might be doable?

As previously discussed, SELinux used to only support exec-based context
transitions, as that is the point where we can control inheritance of
state and initialization of the process in the new context.  It has
never supported context transitions upon fork.  Recently (again, as
discussed on the list), support for dynamic context transitions via the
new setcon(3) libselinux function was added, which would allow sshd to
explicitly transition domains for the different processes without
performing an exec.  But it would be better to restructure it instead to
use exec-based transitions for better security...

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Tue, Feb 15, 2005 at 02:22:22PM -0500, Stephen Smalley wrote:

> >   what the _heck_ is that sshd doing still running as root, or
> >   more specifically, what's it doing still running under sshd_t?
> 
> Isn't this the normal privilege separation support in sshd, with the
> parent being the privileged monitor and the child as the user
> unprivileged process?  See
> http://www.citi.umich.edu/u/provos/ssh/privsep.html
 
 yes - it would look like it is.  thanks for the reference.

> >  unfortunately, then, as things stand, it's not possible to
> >  associate a security context with the "initial" fork - the
> >  one that holds the TCP connection.
> > 
> >  ... and what you are saying is that now that dynamic transitions
> >  are possible, it might be doable?
> 
> As previously discussed, SELinux used to only support exec-based context
> transitions, as that is the point where we can control inheritance of
> state and initialization of the process in the new context.  It has
> never supported context transitions upon fork.  Recently (again, as
> discussed on the list), support for dynamic context transitions via the
> new setcon(3) libselinux function was added, which would allow sshd to
> explicitly transition domains for the different processes without
> performing an exec.  But it would be better to restructure it instead to
> use exec-based transitions for better security...
 
 okay.

 leaving the restructuring issue aside for one moment, in order to
 minimise the amount of work involved, would it be reasonable to
 track the privilege-separated sshd (which is supposed to run in
 an unused user account) with an intermediate security context, using
 a dynamic context transition, if necessary, to get to it?

 e.g. sshd_privsep_$1_t so that in the macros sshd_privsep_user_t
 gets created, and in my case sshd_privset_restricted_user_t.

 and then granting only the necessary networking permissions to that
 intermediate domain, and granting _that_ domain the right to
 transition on an execve() / execution of a shell, rather than
 granting sshd_t the right to transition?

 in this way, i could then add networking contexts to
 sshd_privset_restricted_user_t that only allow the restricted user
 the rights to ssh in to the box from a specific IP address.

 reckon?

 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.

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Tue, Feb 15, 2005 at 08:03:55PM +0000, Luke Kenneth Casson Leighton wrote:

>  leaving the restructuring issue aside for one moment, in order to
>  minimise the amount of work involved, would it be reasonable to
>  track the privilege-separated sshd (which is supposed to run in
>  an unused user account) with an intermediate security context, using
>  a dynamic context transition, if necessary, to get to it?
 
 and, sorry for asking a second question in this fashion, but
 if so, how would i derive the context which to dynamically
 transition to?

 i couldn't use get_default_context() ... or could i?

 it'd involve calling the new lovely setcon(), i know that.

 i assume it's possible to "catch" that and trigger something
 similar to domain_auto_trans()?

 i notice from the 2.6.10 patches that there's something called
 "dyntransition" now - and also "setcurrent".

 okay.... so... what's the format... what would dynamic_auto_trans()
 look like?

 this?

	 #################################
	 #
	 # dynamic_auto_trans(parent_domain, program_type, child_domain)
	 #
	 # Define a default domain transition and allow it.
	 #
	 define(`dynamic_auto_trans',`
	 dynamic_trans($1,$2,$3)
	 type_transition $1 $2:process $3;
	 ')

 and then, dynamic_trans() :

	...
	allow $1 $3:process dyntransition
	...

 ... and identical stuff other than that to domain_trans()?


 
 p.s. i've found the point in the openssh code at which the privilege
 separation occurs - the function is helpfully called
 privsep_preauth_child().


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

Re: sshd transition points

[Stephen Smalley]

On Tue, 2005-02-15 at 15:57, Luke Kenneth Casson Leighton wrote:
>  and, sorry for asking a second question in this fashion, but
>  if so, how would i derive the context which to dynamically
>  transition to?
> 
>  i couldn't use get_default_context() ... or could i?
> 
>  it'd involve calling the new lovely setcon(), i know that.

At present, you can't use get_default_context() because it only returns
contexts for which 'transition' permission has been allowed, not
'dyntransition'.  Whether or not we should change the internal logic
(which ultimately goes down to the kernel's /selinux/user interface) to
also return contexts for dynamic transitions or instead introduce a
separate interface for this purpose is not clear.

Further, get_default_context() is only suitable when getting a default
context for a user session.  In this case, you want domains for the
monitor process and the unprivileged child process, neither of which are
associated with a user.  Hence, I'd just pull them out of a config file.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 08:02:53AM -0500, Stephen Smalley wrote:
> On Tue, 2005-02-15 at 15:57, Luke Kenneth Casson Leighton wrote:
> >  and, sorry for asking a second question in this fashion, but
> >  if so, how would i derive the context which to dynamically
> >  transition to?
> > 
> >  i couldn't use get_default_context() ... or could i?
> > 
> >  it'd involve calling the new lovely setcon(), i know that.
> 
> At present, you can't use get_default_context() because it only returns
> contexts for which 'transition' permission has been allowed, not
> 'dyntransition'.  Whether or not we should change the internal logic
> (which ultimately goes down to the kernel's /selinux/user interface) to
> also return contexts for dynamic transitions or instead introduce a
> separate interface for this purpose is not clear.
 
 ah.

> Further, get_default_context() is only suitable when getting a default
> context for a user session.  

 yes.

 that's what i would like to do: create an ssh-specific user context
 from being already in sshd_priv_t and from user_t.


> In this case, you want domains for the
> monitor process and the unprivileged child process, neither of which are
> associated with a user.  

 ah, but because the unprivileged child process in this instance manages
 the networking, and because i wish to restrict users on a per-IP basis
 from being able to log in, i _do_ want to associate a user-specific
 domain with the unprivileged child process.

 even if it's for a few microseconds and it immediately transitions to
 something with even less privileges (again, using setcon).

	 sshd_priv_pre_auth_t -> sshd_priv_user_t -> sshd_priv_t

> Hence, I'd just pull them out of a config file.
 
 yuk :)

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

Re: sshd transition points

[Stephen Smalley]

On Wed, 2005-02-16 at 08:51, Luke Kenneth Casson Leighton wrote:
>  ah, but because the unprivileged child process in this instance manages
>  the networking, and because i wish to restrict users on a per-IP basis
>  from being able to log in, i _do_ want to associate a user-specific
>  domain with the unprivileged child process.

I'm not sure that this makes sense; isn't the monitor process and the
unprivileged child process created _before_ authenticating the user?  It
isn't until you create the user privileged child process that you have
an authenticated user identity.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 08:41:12AM -0500, Stephen Smalley wrote:
> On Wed, 2005-02-16 at 08:51, Luke Kenneth Casson Leighton wrote:
> >  ah, but because the unprivileged child process in this instance manages
> >  the networking, and because i wish to restrict users on a per-IP basis
> >  from being able to log in, i _do_ want to associate a user-specific
> >  domain with the unprivileged child process.
> 
> I'm not sure that this makes sense; isn't the monitor process and the
> unprivileged child process created _before_ authenticating the user?  

 ahh..... ummmm... 

> It
> isn't until you create the user privileged child process that you have
> an authenticated user identity.

 let me have a look and see if i can find out from the source code.

 once authenticated, there has to be an "unprivileged" process
 which deals with networking on behalf of the user-process,
 using pipes to communicate between the two.

 irrespective of which process it is (the monitor one, the privsep one)
 i will still need to associated a user-based context with it,
 because that process, in dealing with networking, is the only place
 where i can put the per-ip-per-user networking restrictions
 (modified/derived version of can_network).

 okay.

 sshd.c's privsep_preauth() does the fork() and the child process
 is the one that drops privileges into sshd and does the chroot.

 [after the child comes out of privsep_preauth(), it drops
  into calling do_authentication or do_authentication2, followed
  by an exit() - at line 1486 of sshd.c in openssh-3.8.1p1]

 the parent calls privsep_postauth, which sets up the pipe,
 then does a fork again.
 
 the parent then does do_setusercontext() and then goes on to
 call do_authenticated() after it comes out of privsep_postauth().

 the [second] child continuously calls monitor_read() forever.


 SO!

 it's do_
 what i need to do is to have do_authentication2() perform
 the setcon() to the intermediate "sshd_priv_<role>_t" context
 AS SOON as it is established what the username is going to be.

 then, any further networking would potentially be interrupted
 by the modified/derived can_network() function, such that
 if you ain't coming in from the right IP address, you ain't
 gonna get authenticated.

 l.


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

okay: am i being particularly thick today, or am i missing something?

we expect domain automatic transitions to occur on an execve().
it's how everything hangs together in selinux.

_should_ i expect automatic transitions to be possible on
a "dynamic" transition?

because, without them, things get a bit inconvenient.

i wrote a code-fragment earlier where i do a get_default_context(),
and then i do a setcon().

on the setcon(), because i happened to be in sshd_privsep_t, and because
i happened to be setting the context to user_t, and because it was
sshd_exec_t doing the setting, i expect an "automatic" transition
to occur to sshd_privsep_user_t.


otherwise, what i am going to have to do makes me feel slightly
queasy, and if i recall correctly, it's what made me think "how the 
heck am i gonna do that???" when i was considering this for samba tng.

if you recall, i mentioned something about munging security contexts
by digging into the text of a struct security_context - by MANUALLY
creating a string:

	char new_context[500];
	context = get_default_context(..., &scontext);
	sprintf(new_context, "samba_%s", (char*)scontext));
	setcon((struct security_context*)new_context);

EEEEEUUUUWWW, yukkk, i hear you say.

yeh, yuk.  a really awful hack, that leads to croo-joze nasties
and hard-coded context names and stuff .... in an application.

well, if there existed that dynamic_auto_trans() macro - and
support for it in hooks.c - then the problem of hard-coded
security contexts ... melts away and disappears.

why?  because it would be possible to do this:

	dynamic_auto_trans(sshd_privsep_t, user_t, sshd_exec_t,
			   sshd_privsep_user_t)


and in sshd, just do this:

	get_default_context(&scontext), /* gets user_t or other user context */
	setcon(&scontext).

ta-daa.

good idea?

like it?

good.  patch attached.

l.

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

[-- Attachment #2: f --]
[-- Type: text/plain, Size: 2018 bytes --]

? .hooks.c.swp
? f
? ss/.services.c.swp
Index: hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.32
diff -u -r1.32 hooks.c
--- hooks.c	4 Feb 2005 18:09:20 -0000	1.32
+++ hooks.c	15 Feb 2005 22:41:27 -0000
@@ -4080,6 +4080,52 @@
 	return len;
 }
 
+/*
+ * purpose of this function is to determine if a dynamic auto-transition
+ * should occur.  if you were in context "fromsid", and are attempting
+ * to set the context as "sid", then instead, it gets set to "newsid".
+ *
+ * just like in selinux_bprm_set_security(), from which this function
+ * is derived (and is near-identical).
+ *
+ */
+static int selinux_check_dyn_autotrans( u32 fromsid, u32 sid, u32 *newsid)
+{
+	int rc;
+
+	/* Check for a default transition on this
+	 * dynamic context transition.  */
+	rc = security_transition_sid(fromsid, sid,
+			     SECCLASS_PROCESS, newsid);
+
+	if (rc)
+	{
+		/* we do _not_ have permission to do an auto-dyn-trans.
+		 * therefore, the sid to change to is the one that
+		 * the setcon() actually asked for.
+		 */
+		*newsid = sid;
+		return 0;
+	}
+
+        if (fromsid == *newsid) {
+		rc = avc_has_perm(fromsid, sid,
+				  SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, NULL);
+		return rc;
+	}
+
+	/* Check permissions for the transition. */
+	rc = avc_has_perm(fromsid, newsid, SECCLASS_PROCESS,
+			  PROCESS__TRANSITION, NULL);
+	if (rc)
+		return rc;
+
+	rc = avc_has_perm(newsid, sid, SECCLASS_FILE,
+			  FILE__ENTRYPOINT, NULL);
+
+	return rc;
+}
+
 static int selinux_setprocattr(struct task_struct *p,
 			       char *name, void *value, size_t size)
 {
@@ -4169,7 +4215,16 @@
 			if (error)
 				return error;
 		} else {
-			tsec->sid = sid;
+			u32 newsid;
+			int rc;
+
+			rc = selinux_check_dyn_autotrans( tsec->sid, sid,
+					                  &newsid);
+			if (rc)
+				tsec->sid = sid; /* nope - no auto-trans */
+			else
+				tsec->sid = newsid;
+
 			task_unlock(p);
 		}
 	}

Re: sshd transition points

[Luke Kenneth Casson Leighton]

okay.

i should explain what this patch actually does, shouldn't i? :)

on a setcon, if you are in context A, and you are endeavouring to
setcon to context B, then you "automatically" get thrown instead
into context C.

i cut/paste bits of selinux_bprm_set_security(), to set a requirement
to have two permissions "transition:process" and "entrypoint:file" and
of course, looking at that now, that's COMPLETELY wrong :)

it maybe should be transition:process and also dyntransition:process,
if anything.

don't know.

anyway.

it needs to be matched by a macro dynamic_auto_trans(), which
should be used like this:

	dynamic_auto_trans(A, B, C)

according to the description above about setcon().

	define(`dynamic_auto_trans',`
	dynamic_trans($1,$2,$3)
	type_transition $1 $2:process $3;
	')

and this is the complicated one that i don't quite follow but
i notice from domain_trans there's "allow $3 $2:file entrypoint"
which is what i got wrong in my patch so something like this perhaps?

	define (`dynamic_trans',`

	allow $1 $3:process dyntransition;
	allow $3 $2:process transition;
	')

and then where i have put this:

	> +
	> +	/* Check permissions for the transition. */
	> +	rc = avc_has_perm(fromsid, newsid, SECCLASS_PROCESS,
	> +			  PROCESS__TRANSITION, NULL);
	> +	if (rc)
	> +		return rc;
	> +
	> +	rc = avc_has_perm(newsid, sid, SECCLASS_FILE,
	> +			  FILE__ENTRYPOINT, NULL);
	> +

have this instead:

	> +
	> +	/* Check permissions for the transition. */
	> +	rc = avc_has_perm(fromsid, newsid, SECCLASS_PROCESS,
	> +			  PROCESS__DYNTRANSITION, NULL);
	> +	if (rc)
	> +		return rc;
	> +
	> +	rc = avc_has_perm(newsid, sid, SECCLASS_FILE,
	> +			  PROCESS_TRANSITION, NULL);
	> +

i dunno.  i grok the principle, but the details escape me - esp.
the rest of the weird bits in domain_trans() whose purpose i don't
know about.

but the benefits are very very obvious: no pissing about
with hard-coding contexts, type-casting security_contexts to
strings, constructing them and re-typecasting strings back
to security_contexts.

the security contexts can be specified where they belong -
in the policy.

and i can modify the policy to include my lovely paranoid sshd
messings about.

which i certainly could NOT do WITHOUT this dynamic_auto_trans():
i would have to hack sshd about, which is unacceptable [for
the production environment in which it is to be deployed.  the
fact that FC3 is to be used has only been accepted by the skin
of its teeth].


the only caveat is that the security_transition_sid() function
ONLY takes two arguments to produce a third.

ideally, i'd like to see a specific executable be thrown into
the mix as well: three arguments to the security_transition_sid
function to produce a fourth:

dynamic_auto_trans(sshd_privset_t, user_t, sshd_exec_t, sshd_privset_user_t)
                                           ^^^^^^^^^^^

... would that be doable?

l.

On Tue, Feb 15, 2005 at 10:53:29PM +0000, Luke Kenneth Casson Leighton wrote:
> okay: am i being particularly thick today, or am i missing something?
> 
> we expect domain automatic transitions to occur on an execve().
> it's how everything hangs together in selinux.
> 
> _should_ i expect automatic transitions to be possible on
> a "dynamic" transition?
> 
> because, without them, things get a bit inconvenient.
> 
> i wrote a code-fragment earlier where i do a get_default_context(),
> and then i do a setcon().
> 
> on the setcon(), because i happened to be in sshd_privsep_t, and because
> i happened to be setting the context to user_t, and because it was
> sshd_exec_t doing the setting, i expect an "automatic" transition
> to occur to sshd_privsep_user_t.
> 
> 
> otherwise, what i am going to have to do makes me feel slightly
> queasy, and if i recall correctly, it's what made me think "how the 
> heck am i gonna do that???" when i was considering this for samba tng.
> 
> if you recall, i mentioned something about munging security contexts
> by digging into the text of a struct security_context - by MANUALLY
> creating a string:
> 
> 	char new_context[500];
> 	context = get_default_context(..., &scontext);
> 	sprintf(new_context, "samba_%s", (char*)scontext));
> 	setcon((struct security_context*)new_context);
> 
> EEEEEUUUUWWW, yukkk, i hear you say.
> 
> yeh, yuk.  a really awful hack, that leads to croo-joze nasties
> and hard-coded context names and stuff .... in an application.
> 
> well, if there existed that dynamic_auto_trans() macro - and
> support for it in hooks.c - then the problem of hard-coded
> security contexts ... melts away and disappears.
> 
> why?  because it would be possible to do this:
> 
> 	dynamic_auto_trans(sshd_privsep_t, user_t, sshd_exec_t,
> 			   sshd_privsep_user_t)
> 
> 
> and in sshd, just do this:
> 
> 	get_default_context(&scontext), /* gets user_t or other user context */
> 	setcon(&scontext).
> 
> ta-daa.
> 
> good idea?
> 
> like it?
> 
> good.  patch attached.
> 
> l.
> 
> -- 
> --
> <a href="http://lkcl.net">http://lkcl.net</a>
> --

> ? .hooks.c.swp
> ? f
> ? ss/.services.c.swp
> Index: hooks.c
> ===================================================================
> RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
> retrieving revision 1.32
> diff -u -r1.32 hooks.c
> --- hooks.c	4 Feb 2005 18:09:20 -0000	1.32
> +++ hooks.c	15 Feb 2005 22:41:27 -0000
> @@ -4080,6 +4080,52 @@
>  	return len;
>  }
>  
> +/*
> + * purpose of this function is to determine if a dynamic auto-transition
> + * should occur.  if you were in context "fromsid", and are attempting
> + * to set the context as "sid", then instead, it gets set to "newsid".
> + *
> + * just like in selinux_bprm_set_security(), from which this function
> + * is derived (and is near-identical).
> + *
> + */
> +static int selinux_check_dyn_autotrans( u32 fromsid, u32 sid, u32 *newsid)
> +{
> +	int rc;
> +
> +	/* Check for a default transition on this
> +	 * dynamic context transition.  */
> +	rc = security_transition_sid(fromsid, sid,
> +			     SECCLASS_PROCESS, newsid);
> +
> +	if (rc)
> +	{
> +		/* we do _not_ have permission to do an auto-dyn-trans.
> +		 * therefore, the sid to change to is the one that
> +		 * the setcon() actually asked for.
> +		 */
> +		*newsid = sid;
> +		return 0;
> +	}
> +
> +        if (fromsid == *newsid) {
> +		rc = avc_has_perm(fromsid, sid,
> +				  SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, NULL);
> +		return rc;
> +	}
> +
> +	/* Check permissions for the transition. */
> +	rc = avc_has_perm(fromsid, newsid, SECCLASS_PROCESS,
> +			  PROCESS__TRANSITION, NULL);
> +	if (rc)
> +		return rc;
> +
> +	rc = avc_has_perm(newsid, sid, SECCLASS_FILE,
> +			  FILE__ENTRYPOINT, NULL);
> +
> +	return rc;
> +}
> +
>  static int selinux_setprocattr(struct task_struct *p,
>  			       char *name, void *value, size_t size)
>  {
> @@ -4169,7 +4215,16 @@
>  			if (error)
>  				return error;
>  		} else {
> -			tsec->sid = sid;
> +			u32 newsid;
> +			int rc;
> +
> +			rc = selinux_check_dyn_autotrans( tsec->sid, sid,
> +					                  &newsid);
> +			if (rc)
> +				tsec->sid = sid; /* nope - no auto-trans */
> +			else
> +				tsec->sid = newsid;
> +
>  			task_unlock(p);
>  		}
>  	}


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

[patch] dynamic auto trans

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

updated "dynamic auto trans" patch.

corrected some of my misunderstandings from the cut/paste i
did, earlier.

removes some of the stuff that was accidentally file-based, derived
from domain_auto_trans which of course needs an executable and
therefore a sid from a file (which is inapplicable in this case).

the dynamic-auto-trans is based on the context (sid) you were,
and the context (sid) you want to be - no executables are involved.

unfortunately.


anyway.

maybe that additional avc checks should be PROCESS__SETCURRENT?
such that the second avc check in selinux_check_dyn_autotrans
should be this?

	/* Check permissions for the transition. */
	rc = avc_has_perm(fromsid, newsid, SECCLASS_PROCESS,
			PROCESS__DYNTRANSITION, NULL);
	if (rc)
		return rc;

        rc = avc_has_perm(newsid, sid, SECCLASS_PROCESS,
	                          PROCESS__SETCURRENT, NULL);

anyone got a clue, 'cos i haven't!

l.

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

[-- Attachment #2: f --]
[-- Type: text/plain, Size: 2018 bytes --]

? .hooks.c.swp
? f
? ss/.services.c.swp
Index: hooks.c
===================================================================
RCS file: /cvsroot/selinux/nsa/linux-2.6/security/selinux/hooks.c,v
retrieving revision 1.32
diff -u -r1.32 hooks.c
--- hooks.c	4 Feb 2005 18:09:20 -0000	1.32
+++ hooks.c	15 Feb 2005 22:41:27 -0000
@@ -4080,6 +4080,52 @@
 	return len;
 }
 
+/*
+ * purpose of this function is to determine if a dynamic auto-transition
+ * should occur.  if you were in context "fromsid", and are attempting
+ * to set the context as "sid", then instead, it gets set to "newsid".
+ *
+ * just like in selinux_bprm_set_security(), from which this function
+ * is derived (and is near-identical).
+ *
+ */
+static int selinux_check_dyn_autotrans( u32 fromsid, u32 sid, u32 *newsid)
+{
+	int rc;
+
+	/* Check for a default transition on this
+	 * dynamic context transition.  */
+	rc = security_transition_sid(fromsid, sid,
+			     SECCLASS_PROCESS, newsid);
+
+	if (rc)
+	{
+		/* we do _not_ have permission to do an auto-dyn-trans.
+		 * therefore, the sid to change to is the one that
+		 * the setcon() actually asked for.
+		 */
+		*newsid = sid;
+		return 0;
+	}
+
+        if (fromsid == *newsid) {
+		rc = avc_has_perm(fromsid, sid,
+				  SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, NULL);
+		return rc;
+	}
+
+	/* Check permissions for the transition. */
+	rc = avc_has_perm(fromsid, newsid, SECCLASS_PROCESS,
+			  PROCESS__TRANSITION, NULL);
+	if (rc)
+		return rc;
+
+	rc = avc_has_perm(newsid, sid, SECCLASS_FILE,
+			  FILE__ENTRYPOINT, NULL);
+
+	return rc;
+}
+
 static int selinux_setprocattr(struct task_struct *p,
 			       char *name, void *value, size_t size)
 {
@@ -4169,7 +4215,16 @@
 			if (error)
 				return error;
 		} else {
-			tsec->sid = sid;
+			u32 newsid;
+			int rc;
+
+			rc = selinux_check_dyn_autotrans( tsec->sid, sid,
+					                  &newsid);
+			if (rc)
+				tsec->sid = sid; /* nope - no auto-trans */
+			else
+				tsec->sid = newsid;
+
 			task_unlock(p);
 		}
 	}

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Tue, Feb 15, 2005 at 11:17:07PM +0000, Luke Kenneth Casson Leighton wrote:
> okay.
> 
> i should explain what this patch actually does, shouldn't i? :)
> 
> on a setcon, if you are in context A, and you are endeavouring to
> setcon to context B, then you "automatically" get thrown instead
> into context C.

example:

	to track the privilege-separated process that handles
	a user's networking communications for you, and thereby
	to be able to "ban" a specific user from being able to
	ssh into your server except from a specific ip address.

in domain/program/ssh.te:

	# to cover the setcon
	dynamic_auto_trans(sshd_privsep_t, restricteduser_t,
	                   sshd_privsep_restricteduser_t)

	# to cover the execve of the execution of the sftp-server
	domain_auto_trans(sshd_privsep_user_t, sshd_sftp_exec_t,
	                  sftp_restricteduser_t)

then i can create a network context:

	nodecon 192.168.0.220 255.255.255.255 system_u:object_r:restricted_ip_t
	        ^^^^^^^^^^^^^

then, instead of using can_network(), i would do this:

	allow sshd_privset_restricteduser_t netif_type:netif      { tcp_send };
	allow sshd_privset_restricteduser_t restricted_ip_t:netif { tcp_recv };
	                                    ^^^^^^^^^^^^^^^

and, in openssh, to finish it off (somewhere around the privsep
child auth function), i do this:

	/* we are in sshd_privsep_t context when this is done,
	 * but how we got there is TBD... */

	get_default_context(.... &scontext);
	setcon(scontext); /* this triggers the dynamic_auto_trans */

if it wasn't for openssh deploying privilege separation [an intermediate
highly restricted process handling networking] then all this lovely
stuff would be completely unnecessary.


... isn't this a _lot_ simpler than pissing about creating hard-coded
security contexts, or fiddling around adding kludges into libselinux
to be able to create security contexts or read some pseudo-default?

l.


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

Re: sshd transition points

[Stephen Smalley]

On Tue, 2005-02-15 at 19:04, Luke Kenneth Casson Leighton wrote:
> ... isn't this a _lot_ simpler than pissing about creating hard-coded
> security contexts, or fiddling around adding kludges into libselinux
> to be able to create security contexts or read some pseudo-default?

Auto-magically changing the context passed in by the setcon(3) by the
application considered harmful.  If the application wants such
derivations, it calls security_compute_create() first, then calls
setcon() on the result.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 08:10:25AM -0500, Stephen Smalley wrote:
> On Tue, 2005-02-15 at 19:04, Luke Kenneth Casson Leighton wrote:
> > ... isn't this a _lot_ simpler than pissing about creating hard-coded
> > security contexts, or fiddling around adding kludges into libselinux
> > to be able to create security contexts or read some pseudo-default?
> 
> Auto-magically changing the context passed in by the setcon(3) by the
> application considered harmful.  

 out of curiosity: why?

 if it's specified in the policy, and there are permissions
 required for it to occur, what is the harm?

 the only thing i can think of that is possibly harmful is
 that it's not linked to an executable.


> If the application wants such
> derivations, it calls security_compute_create() first, then calls
> setcon() on the result.
 
 ah _ha_ - so there is a programmatic way to do the same thing, without
 hard-coded messing about with modifying contexts.

 okay.
 
 _great_.

 so.

 what rules must be placed in the policy such that
 security_compute_create will produce the desired results, for example:

	/* Compute a labeling decision and set *newcon to refer to it.
	   Caller must free via freecon. */
	   extern int security_compute_create(security_context_t scon,
					security_context_t tcon,
					security_class_t tclass,
					security_context_t *newcon);

 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?

 should it be SECCLASS_PROCESS? 

 ta.

 l.
 
 


> -- 
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency
> 

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

Re: sshd transition points

[Stephen Smalley]

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

>  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
security_transition_sid in the old pre-2.6 SELinux API (and that is
still the internal kernel function), but was renamed along with the
other APIs to reflect the elimination of SIDs from the kernel interface,
to avoid common misunderstandings (people often thought it caused a
transition rather than computing one, and they often thought that it was
used to relabel an object rather than to compute one for a new one), and
to provide a consistent naming convention - see selinux-doc/PORTING. 
Possibly a mistake to not retain transition in the name since that is
still the name for the rules in the policy.

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

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

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

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.

Re: sshd transition points

[Luke Kenneth Casson Leighton]

stephen, i believe i have enough to go on, now: thank you for your
help, even if it's not entirely clear what i want to achieve here :)

i aim to add a setcon() into sshd's "input_userauth_request()"
function just after the point where the username is obtained,
such that any unauthorised IP addresses for that username will
immediately stop any further TCP traffic.

i will add a type_transition to the policy

	 type_transition sshd_priv_t user_t:process sshd_priv_user_t;

i will temporarily use get_default_context() - if it works - to
obtain the user_t context, as the 2nd argument to
security_compute_create().

i will use security_compute_create() to look up the actual context
in my type_transition policy rule (sshd_priv_user_t).

i will use setcon() to actually set the required context
(sshd_priv_user_t).

i will restrict sshd_priv_user_t to only be allowed TCP send and
receive from a specific IP address.

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.

Re: sshd transition points

[Luke Kenneth Casson Leighton]

just fyi: this is an actual real-world deployment of SE/Linux for
a Bastion Server, where it is necessary to restrict which users
may sftp in and upload files on the box - and also to restrict
the users to only one particular directory - _and_ also to restrict
which IP addresses those users can come in on.

so it's actually quite an exciting project.

bearing in mind that it is possible to compromise or just
absent-mindedly or otherwise in a blaze fashion copy ssh
private keys (esp. amongst security-unconscious users) it
becomes necessary to restrict one set of sftp users from being
able to sftp in to another customer's upload directory.

yes, the iptables approach works fine - right up to the point
where you run out of virtual interfaces because of the number
of different customers that the Bastion Server is supporting.

l.

On Wed, Feb 16, 2005 at 03:26:45PM +0000, Luke Kenneth Casson Leighton wrote:
> stephen, i believe i have enough to go on, now: thank you for your
> help, even if it's not entirely clear what i want to achieve here :)
> 
> i aim to add a setcon() into sshd's "input_userauth_request()"
> function just after the point where the username is obtained,
> such that any unauthorised IP addresses for that username will
> immediately stop any further TCP traffic.

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

Re: sshd transition points

[Peter K. Lee]

Luke, I was wondering why you can't use sshd_config like this:

AllowUsers \
	restricted_user1@192.168.0.223 \
	restricted_user2@192.168.0.224 \
	...

Also, wouldn't using SE/Linux to do per/user/IP ACL, you need an entry
in the policy (file?) for every user?  And the policy can be reloaded
during run-time of the system every time it gets modified?  (sorry, I
have _no_ idea how SE/Linux works yet...)

-Peter



On Wed, 2005-02-16 at 09:50, Luke Kenneth Casson Leighton wrote:
> just fyi: this is an actual real-world deployment of SE/Linux for
> a Bastion Server, where it is necessary to restrict which users
> may sftp in and upload files on the box - and also to restrict
> the users to only one particular directory - _and_ also to restrict
> which IP addresses those users can come in on.
> 
> so it's actually quite an exciting project.
> 
> bearing in mind that it is possible to compromise or just
> absent-mindedly or otherwise in a blaze fashion copy ssh
> private keys (esp. amongst security-unconscious users) it
> becomes necessary to restrict one set of sftp users from being
> able to sftp in to another customer's upload directory.
> 
> yes, the iptables approach works fine - right up to the point
> where you run out of virtual interfaces because of the number
> of different customers that the Bastion Server is supporting.
> 
> l.
> 
> On Wed, Feb 16, 2005 at 03:26:45PM +0000, Luke Kenneth Casson Leighton wrote:
> > stephen, i believe i have enough to go on, now: thank you for your
> > help, even if it's not entirely clear what i want to achieve here :)
> > 
> > i aim to add a setcon() into sshd's "input_userauth_request()"
> > function just after the point where the username is obtained,
> > such that any unauthorised IP addresses for that username will
> > immediately stop any further TCP traffic.
> 
> --
> 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.

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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 09:59:17AM -0800, Peter K. Lee wrote:
> Luke, I was wondering why you can't use sshd_config like this:
> 
> AllowUsers \
> 	restricted_user1@192.168.0.223 \
> 	restricted_user2@192.168.0.224 \
> 	...
 
 hey, that's a good idea.  duh :)

> Also, wouldn't using SE/Linux to do per/user/IP ACL, you need an entry
> in the policy (file?) for every user?  

 well, in my case, ever user role, but yes.


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 09:59:17AM -0800, Peter K. Lee wrote:
> Luke, I was wondering why you can't use sshd_config like this:
> 
> AllowUsers \
> 	restricted_user1@192.168.0.223 \
> 	restricted_user2@192.168.0.224 \
> 	...
 

 AllowUsers appears to be capable of doing wildcards
 even on IP addresses, so yeah, looks like it'd be
 useable.

 three ways to skin a cat...

 ta.

 l.


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

Re: sshd transition points

[Stephen Smalley]

On Wed, 2005-02-16 at 10:26, Luke Kenneth Casson Leighton wrote:
> i aim to add a setcon() into sshd's "input_userauth_request()"
> function just after the point where the username is obtained,
> such that any unauthorised IP addresses for that username will
> immediately stop any further TCP traffic.

And this occurs in the unprivileged child process, not the monitor?  So
the unprivileged child will timeout waiting for further input, die, and
the monitor will cleanup?

> i will add a type_transition to the policy
> 
> 	 type_transition sshd_priv_t user_t:process sshd_priv_user_t;
> 
> i will temporarily use get_default_context() - if it works - to
> obtain the user_t context, as the 2nd argument to
> security_compute_create().
> 
> i will use security_compute_create() to look up the actual context
> in my type_transition policy rule (sshd_priv_user_t).

And where does sshd_priv_t come from?  Unless you make some other
change, you are still running in sshd_t at this point, right?

> i will use setcon() to actually set the required context
> (sshd_priv_user_t).
> 
> i will restrict sshd_priv_user_t to only be allowed TCP send and
> receive from a specific IP address.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 12:53:38PM -0500, Stephen Smalley wrote:
> On Wed, 2005-02-16 at 10:26, Luke Kenneth Casson Leighton wrote:
> > i aim to add a setcon() into sshd's "input_userauth_request()"
> > function just after the point where the username is obtained,
> > such that any unauthorised IP addresses for that username will
> > immediately stop any further TCP traffic.
> 
> And this occurs in the unprivileged child process, not the monitor?  

 looks like it, yes.

> So
> the unprivileged child will timeout waiting for further input, die, and
> the monitor will cleanup?

 yes, it most likely will have to.

> > i will add a type_transition to the policy
> > 
> > 	 type_transition sshd_priv_t user_t:process sshd_priv_user_t;
> > 
> > i will temporarily use get_default_context() - if it works - to
> > obtain the user_t context, as the 2nd argument to
> > security_compute_create().
> > 
> > i will use security_compute_create() to look up the actual context
> > in my type_transition policy rule (sshd_priv_user_t).
> 
> And where does sshd_priv_t come from?  

> Unless you make some other
> change, you are still running in sshd_t at this point, right?
 
 yes.

 i dreamed up sshd_priv_t for no particular reason other than it
 would conceivably be better to run setcon("sshd_priv_t") first
 on the unprivileged child process, followed by the
 security_compute_create(), such that creating

	type_transition sshd_priv_t user_t:process sshd_priv_user_t;

 doesn't interfere with anything to do with sshd_t.

 plus, of course, it would be possible to lock down a set
 of insanely restrictive rules for sshd_priv_t (involving
 networking and pretty much nothing else), with the implicit
 possibility that sshd_t could have some networking permissions
 removed.

 l.


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

Re: sshd transition points

[Stephen Smalley]

On Tue, 2005-02-15 at 17:53, Luke Kenneth Casson Leighton wrote:
> on the setcon(), because i happened to be in sshd_privsep_t, and because
> i happened to be setting the context to user_t, and because it was
> sshd_exec_t doing the setting, i expect an "automatic" transition
> to occur to sshd_privsep_user_t.

That makes no sense.  If you want to compute a derived context to pass
to the setcon() call, you can use security_compute_create() to get one
from policy, e.g. see the corresponding logic in rpm_execcon(3) in
libselinux.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 08:08:00AM -0500, Stephen Smalley wrote:
> On Tue, 2005-02-15 at 17:53, Luke Kenneth Casson Leighton wrote:
> > on the setcon(), because i happened to be in sshd_privsep_t, and because
> > i happened to be setting the context to user_t, and because it was
> > sshd_exec_t doing the setting, i expect an "automatic" transition
> > to occur to sshd_privsep_user_t.
> 
> That makes no sense.  If you want to compute a derived context to pass
> to the setcon() call, you can use security_compute_create() to get one
> from policy, 

 okay, my apologies: i wasn't aware of this function.


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

Re: sshd transition points

[Stephen Smalley]

On Tue, 2005-02-15 at 15:03, Luke Kenneth Casson Leighton wrote:
>  leaving the restructuring issue aside for one moment, in order to
>  minimise the amount of work involved, would it be reasonable to
>  track the privilege-separated sshd (which is supposed to run in
>  an unused user account) with an intermediate security context, using
>  a dynamic context transition, if necessary, to get to it?

Note that there are several processes involved (based on the diagram):
- the listening sshd
- the parent monitor process
- the unprivileged child for network processing
- the user privileged child for user request processing

Further, note the relationships among these processes (again, based on
the diagram):
- listening sshd forks parent monitor
- parent monitor forks the unprivileged child
- unprivileged child exports state back to the parent monitor and dies
- parent monitor forks and exec's the user privileged child

Hence, dynamic context transitions to two different domains would be
suitable for the parent monitor (e.g. sshd_monitor_t) and for the
unprivileged child (e.g. sshd_unpriv_t).  The user privileged child will
already run in its own domain (user_t or staff_t) due to the existing
logic for setting the user security context upon the execve.
 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: sshd transition points

[Luke Kenneth Casson Leighton]

On Wed, Feb 16, 2005 at 08:00:17AM -0500, Stephen Smalley wrote:
> On Tue, 2005-02-15 at 15:03, Luke Kenneth Casson Leighton wrote:
> >  leaving the restructuring issue aside for one moment, in order to
> >  minimise the amount of work involved, would it be reasonable to
> >  track the privilege-separated sshd (which is supposed to run in
> >  an unused user account) with an intermediate security context, using
> >  a dynamic context transition, if necessary, to get to it?
> 
> Note that there are several processes involved (based on the diagram):
> - the listening sshd
> - the parent monitor process
> - the unprivileged child for network processing

 i believe this is the one that i want to transition
 to sshd_priv_<rolename>_t with setcon().


> - the user privileged child for user request processing

 this is the one that has absolutely no networking access, therefore
 i cannot do any checks on the incoming IP address in this domain
 (<rolename>_t e.g. user_t) to restrict user access on a per-IP-address
 basis.


> Further, note the relationships among these processes (again, based on
> the diagram):
> - listening sshd forks parent monitor
> - parent monitor forks the unprivileged child
> - unprivileged child exports state back to the parent monitor and dies

 if the unprivileged child cannot communicate down the remote
 connection (because sshd_priv_<rolename>_t has banned access
 for that role to access anything but one specific IP address)
 then the job is done.

 ... hm, if the unprivileged child exports state back to the parent
 monitor, then in fact it's the parent monitor that i would need
 to have in sshd_monitor_<rolename>_t.

 hmmm...

> - parent monitor forks and exec's the user privileged child

 i don't intend to make any modifications to this part because
 it serves no purpose for the requirements [restricting remote user
 access on a per-IP address].

> Hence, dynamic context transitions to two different domains would be
> suitable for the parent monitor (e.g. sshd_monitor_t) and for the
> unprivileged child (e.g. sshd_unpriv_t).  The user privileged child will
> already run in its own domain (user_t or staff_t) due to the existing
> logic for setting the user security context upon the execve.

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