elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

Sounds good in general, but I have a few concerns.

First, I'm afraid there will be ways to trick the command interpreter and
make the app display incorrect information about the script to be executed.
Besides, restricting the language to simple commands won't really help (I
can still invoke bash or perl with obfuscated malicious code or simply wget
something wicked) but will set a high entrance barrier for solution
providers who are usually fluent in BASH.
You can try to tell what the script does by running it in some sandbox
first (e.g. in a virtual machine) but that can be circumvented by detecting
the sandboxing and pretending to be harmless. That may be kind of remedied
by automatically generating an AppArmor profile based on sandbox activity,
but that still won't protect from adding a good repo in the sandbox and a
bad repo on user's machine. And most users don't even know what a
repository is...
Moreover, it's quite easy to get past such security measures with a bit of
obfuscation and simple social engineering.

Second, each and every solution must be easily reversible. Like, one-click
reversible. I think somebody pointed me to just the system a while ago...
something like btrfs snapshots might work too, but only for immediate
reversal.

Third, I'd prefer the app to support self-service, like in the current
answers system. The user enters the problem symptoms and gets a list of
solutions, which can have a workaround script attached. Just like in
current answers, these solutions can be rated as helpful or unhelpful.
Piping *every single* support request through live support sounds like a
huge overkill.

Following up on that, users also should be able to open support tickets
from the app, so they can not only apply solutions for known issues but
bring up new issues too. Support tickets may later be converted to bug
reports by the people providing tech support. This will replace direct bug
reporting for non-tech-savvy users because they can't tell if the problem
they're experiencing is a software bug or their mistake. See
https://blueprints.launchpad.net/elementaryweb/+spec/friendly-bug-reportingfor
rationale and details on this point.

As for live support, the user shouldn't have to copy-paste anything at all.
The technician should be able to propose a solution directly to the user,
so the user just sees a confirmation prompt and accepting/declining it is a
one-click process if you trust the sender (but viewing source code of the
solution and maybe other security measuers should be available too).

2012/10/19 Cody Garver <cody@xxxxxxxxxxxxxxxx>

>
>
> ---------- Forwarded message ----------
> From: Raphael Isemann <teemperor@xxxxxxxxx>
> Date: Fri, Oct 19, 2012 at 9:32 AM
> Subject: Neutrino - Top-of-the-line-support for luna+1
> To: Cody Garver <cody@xxxxxxxxxxxxxxxx>
>
>
>  Hi folks :)
>
> let me start with a littlebit of background story (if you don't want to
> read it, go the the TL;DR)
> So, i'm hanging around in the irc-support-channel of elementary since a
> while and also tried to help people with their problems (and i think i
> helped the most of them with their problems). And i made some thoughts on
> the irc-support.
>
> The things i learned (not in that few days, but in my whole time helping
> people with pc-problems over irc etc.)
>
> 1. "USABILITY": It's quite surprising, but helping people with
> tech-problems is fun. The problem is often, that be on the user-side of the
> support is horrible. Some strange guy is asking you to type some things in
> a strange black-white window everyone just knows from a hollywood-films and
> that mostly without extra-information. What does this or that command do?
> There is no time to explain everything, often you just want to have the
> information of specific files etc. and the users feels very unsecure.
>
> => the usual user doesn't like the terminal. The terminal seems like an
> alien in a DE full with simple GUI-Applications, it feels uncomfortable for
> the user, and it's therefore not suitable as a base for the support-part of
> elementary.
>
> 2. "SECURITY": The support of many open-source projects which are not
> leaded by bigger companies consists of anonymous volunteers. This isn't a
> bad thing, but it could be a problem. In an support-irc, you can just tell
> a user to run that command to solve his problem. The user maybe don't know
> that the guy is not 100 % trust able, runs it and in the best case the
> script is just making some destructive stuff.
> Also other people in the irc can't easily check script-commands due to the
> variety of programs and commands.
> The problem is not that big, because we don't have a big userbase yet, and
> the people who do bad things, are just too rare at the moment, but
> eventually it happens.
> What makes this point even worse: Most users don't think anymore about
> typing their password for sudo("Oh, update=>password, USC=>password, ...")
> and it make people even easier to execute them scripts with expanded
> privileges.
>
> ------------- TL;DR --------------------
>
> My proposal is to improve our support to a better level with some little
> extra tool in luna+1.
>
> In very short some kind of definition:
>
> "The application is a simple interpreter/data-aggregator/et**c. what the
> supports needs to help the user with a focus on security and usability. It
> should make the elemenary-support to a top-of-the-line-experience as the
> rest of the elementary project. It's meant to be used by a group of
> supporters who doesn't need to be to recognize themselves to help others
> and stays therefore in the spirit of open-source-support anonymous. All
> communication goes over irc, so both parts doesn't interact directly with
> each other despite the irc-channel."
>
>
> For all those who want it better explained:
> (I don't have a name, i thought on something like "Neutrino" =>
> lightweight and fast, or "First Aid", "Roboto" or what our design-team
> thinks sounds the best, so i just will call it Neutrino in the following):
>
> I think it will be described in best with an example:
>
> 1. The user has an problem with elementaryOS, just say this bug:
> https://bugs.launchpad.**net/elementaryos/+bug/1063067<https://bugs.launchpad.net/elementaryos/+bug/1063067>
>  **. Let's assume he found the irc-channel (or better, the user uses
> "help" in slingshot and will be directed to Neutrino (with a
> description/Name like "Live Support", which directs him to the irc).
> 2. The user tries so explain his problem: "I can't install anything!"
> (Well, it seems that this bug caused this)
> 3. The Supporter A writes to the user that he read his problem and that he
> should wait a moment.
> 4. Supporter A assume that this bug affect this user and types a simple
> script for "Neutrino" which solves the problem which looks like that:
>
> """
> [NEUTRINO_SUPPORT]
> if ["http://de.archive.ubuntu.**com/ubuntu/ luna main restricted"<http://de.archive.ubuntu.com/ubuntu/lunamainrestricted> is_in_file
> "etc/apt/sources.list"]
> {
>     replace "luna"->"precise" in "etc/apt/sources.list";
>     dpkg-update;
>     SUCCESS "replace failed";
> }
> report list "/etc/apt/"
>
> [NEUTRINO_SUPPORT_END]
> """
>
> (Sample-syntax, just an idea)
> 5. (The next step can be changed, to the most suitable form of
> transmitting) Supporter A uploads the script to pastebin-service and the
> link into the irc/Posts the short-script directly into the chat.
> 6. The Supporter tells the user to copy the link with Control+C and then
> open the Application "Neutrino".
> 7. Neutrino opens up and is automatic fetching the Script from the link
> (or the user is copying the script directly into the clipboard and Neutrino
> is reading from there).
> 8. Neutrino analyse the script and rates every command with a security
> level.
> 9. Neutrino shows up a simple GUI which represents the script in an
> understandable form for the most users (as an extra-information):
>
>     ------------------------------**------------------------------**
> ----------
>     |  Neutrino is executing a support-ticket in your Clipboard:
>     |-----------------------------**------------------------------**
> ----------
> 1  |  Neutrino checks if the phrase "http://de.archive.**ubuntu.com/ubuntu/
> luna main restricted"<http://de.archive.ubuntu.com/ubuntu/lunamainrestricted> can
> be found in the file "/etc/apt/sources.list".
>     |        If yes:
> 2  |            Neutrino replaces the changes the phrase "luna" to
> "precise" in "/etc/apt/sources.list".
> 3  |            Neutrino updates the application informations
>     |            Success!
>     |        if no:
> 4  |            Neutrino adds a list of files in the directory "/etc/apt"
>     |-----------------------------**------------------------------**
> ----------
>     |
>     |-----------------------------**------------------------------**
> ----------
>
> 10. Neutrino directly starts with the execution of the script. The
> if-statement command (1) will be instantly executed because it's just a
> read operation and doesn't cause any changes and no security-vulnerables to
> the user.
> 11. Neutrino has found the string in the file, and therefore command 2 has
> to be executed. The problem is, that this operation requires a sudo before
> the command can start. Neutrino now explicitly prompts to the user, that
> the specific command "Neutrino replaces the changes the phrase "luna" to
> "precise" in "/etc/apt/sources.list" wants to change a system-intern file
> and that the user needs to enter his password (gksudo or sth. for that).
> Also Neutrino makes silent a Backup of the file in the home-directory as a
> security.
>
> 12. Command 3 will be executed without a prompt because the user still has
> root-privileges and the command just causes to "apt-get update" itself. If
> the user is installing sth. at the moment, it will wait for that and inform
> the user.
> 13. Neutrino will now prompt: "Neutrino has executed your support-ticket!
> Check if you problem still exists and and talk back to your supporter and
> tell him that Neutrino ended with "replace failed" !".         (caused by
> the command SUCCESS "replace failed");
> 14. Script ends
>
> Summarized the user made not the following things after contacting support
> till solution despite reading:
> -Copy the link and click on the Neutrino-Icon.
> -Enter his password.
>
> Somethings that needs to be explained:
>     To point 10: Neutrino's checking algorithm which commands are "safe"
> (= directly executed) is only possible because the "scripting-language" is
> based on just simple commands. It can cover possiblies all by using a
> whitelist for them.
>
>                         The other types of commands are commands which
> read in the home-directory, which first need to be allowed by the user in a
> simple prompt. Also specific "dangerous" directories where sensisible data
> is stored often can be blocked.
>
>                         The last type is program which needs
> root-privileges.
>
>
>
>     To point 9: The GUI shouldn't be covered by the prompts and a
> indicator should show the current execution status. Also in the GUI every
> command is also                                     indicated with a simple
> icon, how safe it is ( green tick, a lock, warning symbol);
>
>
> Advantages of the System:
>
>     - Users don't get confronted with the terminal unnecessary.
>     - Users get translated informations to the command easily due to the
> possibility to make translations from launchpad
>     - The system can be used directly as a base for the live support (if
> there's no Script in the clipboard, i can show a icon which leads to the
> irc).
>     - Supporters can help faster, because they don't need to explain
> everything to the user.
>     - Supporters can collect faster the required informations (see
> Simulation B below) and help the user.
>     - "Bad Guys/Girls" don't have an easy life anymore
>     - Supporters can easily take a look at the scripts of someone else,
> because the simple commands doesn't allow complicated structures despite
> bash etc.
>
>
> Simulation B: The Failure
>
>     Let's continue the example below at point 10, just that now the
> if-statement evaluates to false.
>     Now the command number 4 will be executed.
>     The report command is a sample for fast data-aggregation. At the end
> of the script, all "report ..." results will be concatenated to a single
> report which will be presented to the user in a copyable format and/or
> uploaded to a pastebin.
>     This allows the supporter with multiple report ... commands to get all
> the informations he need from the user without letting the user open a
> dozen of text-files or sth.
>
>
> Ok, i think that were the most important parts :)
>
> It would be nice if some developers and the design team etc. would
> respond, if they want such an application. If yes, i would take my time to
> write it (in vala) if i get design support a littlebit from the design team
> to make it compilant to the elementary HIG.
>
> Also any changes and improvements are welcome, this should just present my
> first idea.
>
> PS: Beside i'm talking a lot about "Bad Guys" at the irc, i haven't met
> anyone at elementary-channel yet, i hope i haven't offended anyone, you're
> all very nice guys :D!
>
> -Raphael Isemann
>
>
>
> --
> Cody Garver
>
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary