A graceful exit....

2007-06-04 Thread Peter Whittaker
Fellow Ubunteros, Ubuntites, and other Ubuntuphiles,

Balance in life is everything, and sometimes demands in one area take
too much time from others. Sadly, such is the case with my Ubuntuing in
various mailing list and groups and fora. In order to devote the time
deserved to other priorities, I've need to withdraw from active Ubuntu
participation (with decidedly mixed emotions!).

To make as graceful an exit as possible, I will be unassigning or
reassigning any bugs or pages assigned to me, and following up as best I
can on any items I should.

If you are awaiting a comment or response from me, please follow up with
me directly.

Thanks to everyone in the Ubuntu community for a fantastic community
experience and fantastic computer experience!

Keep up the utterly fantastic work,

pww




signature.asc
Description: This is a digitally signed message part
-- 
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


Re: Open Port Indicator?

2007-03-16 Thread Peter Whittaker
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



signature.asc
Description: This is a digitally signed message part
-- 
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