Re: sshd transition points

[Luke Kenneth Casson Leighton <lkcl@xxxxxxxx>]

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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.