On 16/03/07, Peter Whittaker [EMAIL PROTECTED] wrote:
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.
I fail to see why UC[34] would require unauthenticated access.
Passwords do not take long to enter. I can enter my secure password in
around 1sec, no more than 2sec. And a simple password of say '123',
while not in any means secure is at least better than no
authentication at all. So speed of access is not a problem.
You are going to have to come up with a better reason, other that
people don't want to enter password because they are too lazy, to
convince me that allowing unauthenticated access is a good idea.
Arwyn
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
