On 05/13/14 19:46, Davíð Steinn Geirsson wrote:
> Hi,
>
> On Tue, 13 May 2014 13:32:47 +0200
> Joanna Rutkowska <
joa...@invisiblethingslab.com> wrote:
>
>> On 05/13/14 13:25, Andrew B wrote:
>>> On 05/13/14 13:16, Joanna Rutkowska wrote:
>>>> On 05/13/14 02:57, Marek Marczykowski-Górecki wrote:
>>>>> On 12.05.2014 22:41, Joonas Lehtonen wrote:
>>>>>>> How do I stop tor from auto-starting in an AppVM? I added
>>>>>>> both tor and qubes-tor to in the "Services" tab of AppVM and
>>>>>>> unchecked the boxes, but tor still boots when I start the
>>>>>>> AppVM.
>>>>>>
>>>>>>> In addition to using unnecessary resources, this is setting
>>>>>>> up tor-over-tor circuits - which can't be good.
>>>>>>
>>>>>> By coincidence I noticed that my firewallVM (and all other
>>>>>> AppVMs based on the default template) are running a tor process
>>>>>> as well. This reminded me of this qubes-users thread.
>>>>>>
>>>>>> I believe everyone following the steps in [1] will end up with
>>>>>> such a setup but probably no one will notice it because
>>>>>> everything is working fine (and it does no harm, no it doesn't
>>>>>> cause a tor-over-tor setup)
>>>>>>
>>>>>> The qubes-tor package depends on the actual "tor" package from
>>>>>>
torproject.org (it gets installed as a dependency).
>>>>>>
>>>>>> 'qvm-service torvm -e qubes-tor' makes sure that qubes-tor will
>>>>>> only be started on torvm, but the "other" tor is started on all
>>>>>> other VMs anyway.
>>>>>>
>>>>>> You can easily tell whether you see a qubes-tor tor process or
>>>>>> a "vanilla" tor process by looking at the owner. qubes-tor's
>>>>>> tor runs as root, while the native tor is running as an
>>>>>> unprivileged user (_tor). @devs: please consider using an
>>>>>> unprivileged user as well (even if modifications don't survive
>>>>>> a reboot ;)
>>>>>>
>>>>>> The "native" tor from
torproject.org apparently doesn't use
>>>>>> systemd style configs.
>>>>>>
>>>>>> If you want to get rid of the unnecessary second tor instance
>>>>>> you can run this in your templateVM:
>>>>>>
>>>>>> chkconfig --del tor
>>>>>>
>>>>>> (this removes the symlinks in /etc/rcX.d folders for you)
>>>>>
>>>>> I've added both of above suggestions to the package: 1. The
>>>>> service is started as '_tor' user. 2. Native tor is disabled on
>>>>> new installation (if you had previous version installed, you need
>>>>> to disable it manually, just as you've described).
>>>>>
>>>>> New package uploaded to unstable repository.
>>>>>
>>>>>> [1]
http://qubes-os.org/trac/wiki/UserDoc/TorVM
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Just don't get too excited about running as _tor user instead of:
>>>>
>>>>
http://git.qubes-os.org/?p=joanna/core-agent-linux.git;a=blob;f=misc/qubes.sudoers;h=8087a90a8c0a6f81d4fe45905a6aa9462de2a7ce;hb=HEAD
>>>>
>>>>
>>>>
>> :)
>>>>
>>>> But sure, it might make some sense for hygiene reasons, and maybe
>>>> one day we will change this sudoers config, or somebody might build
>>>> a better (community) template.
>>>>
>>>> joanna.
>>>>
>>>
>>> If I remember correctly, David was working on a PAM module that
>>> integrated with Qubes RPC to give Dom0-based user confirmation upon
>>> sudo request. I think that's the way to go...
>>>
>
> Yes, that's one of the things I would like to see in qubes, and I might
> implement it in the future, but I'm not currently working on it. If
> anyone else feels like giving it a shot, please don't stop on my
> account. :)
After looking around the PAM docs for a few minutes, this looked pretty easy, so I coded up a simple implementation (attached). Once again I'm not very interested in making a proper package, so it includes a README file with very simple installation instructions.
This service processes no data whatsoever in Dom0; it merely invokes 'echo 1'. On the AppVM, it implements an extremely simple PAM authentication scheme which merely forks an invocation of the Dom0 RPC service with a local handler of just "grep -q ^1$". When grep's return value indicates a match, the user must have authorized the authentication request in Dom0. Note that I have not considered vulnerability to, e.g. races, where some nefarious program already running in the AppVM somehow intercepts the RPC result or directly modifies memory in the PAM object. I suppose it's probably secure, but outside review is obviously welcome.
Andrew