Open Port Indicator?

Peter Whittaker pwwnow at
Fri Mar 16 12:48:01 UTC 2007

On Thu, 2007-15-03 at 14:14 +0100, Soren Hansen wrote:
> I asked for a use case where it made sense to allow access without any
> form of authentication.
> If no one comes up with a proper use case I'll just hack together a patch
> that makes it impossible.

There are at least four use cases, each of which requires a different
level of authentication/access.

UC1:	Jen needs remote access to her machine. Remote authentication
	should be (at least) the same as local authentication, i.e.,
	userid and password. This should be the default option when
	enabling Remote Desktop (e.g., "Enable remote desktop for known
	users, or for known user X, userid and password required").

	By default, this setting would persist across sessions. This
	could be disabled, making it one time only (that is, until
	logout or reboot).

	As an improvement, there could be a time filter ("during these
	hours only"), a domain filter (yes, spoofable, but perhaps of
	value), an IP or Mac filter (ditto), etc.

UC2:	Bif needs assistance with a problem and invites a remote friend
	to connect and "drive", so Bif can watch and learn. In this
	case, Remote Desktop could prompt the current local user to
	enable the connection from the remote friend (e.g., an "Enable
	remote assistance" option, where each connection is vetted by
	the current local user ("Someone is accessing your machine from
	A.B.C.D - do you wish to permit this connection?") "No" or no
	answer within X seconds means no; yes means yes; a third option
	could be yes, for Y minutes (max value 30, after 30, prompt

	When the current sessions ends (logout, reboot, etc.), Remote
	Desktop returns to its default, disabled. In other words, if
	Bif had previously enabled UC1, he must reenable explicitly
	after using UC2.

UC3:	Fritz is setting up a classroom or other contained environment,
	and wishes to be able to access all local machines quickly and
	easily (for whatever reason). He selects "Enable Remote Desktop
	without authentication", is warned this is potentially risky,
	and is then prompted to enter the shutoff time/period, i.e.,
	the time/period after which Remote Access will be disabled and
	will return to the default of no access.

	Remote Access reverts to disabled after logout/reboot.

UC4:	Barbara is a security researcher setting up a honeypot. She
	wants to enable Remote Access without authentication. This is
	a special case of UC3: No authentication, no time limit. She
	selects no time/period, is asked to confirm this is what she
	really meant, perhaps even twice, three times, whatever makes
	us comfortable.

UC1 and UC2 would require no additional authentication (userid and
password in UC1, local confirmation in UC2). UC3 and UC4 could require
root privileges, e.g., require the use of gksudo. This would reduce the
likelihood of just some person taking advantage of an unlocked local

Alternatively, UC[1234] could require the user to authenticate
themselves when enabling the option, further reducing this risk.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Ubuntu-devel-discuss mailing list