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
