Open Port Indicator?
Peter Whittaker
pwwnow at gmail.com
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
again).
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
keyboard.
Alternatively, UC[1234] could require the user to authenticate
themselves when enabling the option, further reducing this risk.
pww
-------------- 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: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070316/fcb433c9/attachment.sig>
More information about the Ubuntu-devel-discuss
mailing list