Re: [qubes-devel] kernel downgrade

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/29/2018 04:49 PM, Zrubi wrote:
> Any suggestion how to solve this?

Try this:
  sudo qubes-dom0-update --action=downgrade [kernel packages]

> And if I succed, how can I lock my system to this kernel version?

Add the following line into /etc/yum.conf or /etc/dnf/dnf.conf
_outside_ of the section marked with "QUBES BEGIN" and "QUBES END":

  exclude=kernel*


Cheers,
Patrik
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEECa/mcuUTuKPtNWQ7XB5x3wMfmuUFAlq9AMMACgkQXB5x3wMf
muUY0g//c4Rqgkoy43dT4QH9sDLapLakFz+BADLlLR+IJXgTKUSFQV8NDVv85HOE
O6LSaocP/kCoEOeA6AuM3YqWoeYesAWxig1bGlaX4ERgSjq7ORgLUhBFiWwmhBMZ
Om5gSPecCTg6IEjjuP6DNxAn4XmNd6svGWBi53h0Ckiq/VB4txiivjo0yiqsxEsv
3EvFOUXAdXv4/ZWCbqxwxF5K/3D3ClStzszNRhsLAnF3svnP10hn2e7bC9336lyN
OeK1ortmOH8DR2u5r4y/OlDG1geF5iwsbeqhIfQH68iyosE4ZtU94LLObnHMv23M
82S9gNi6BK0dUWhjy4BRoWdKwV5xqyELtytNpOZ7GC806U9yHSUaX/O+CPgj8fbB
l3N5JI2SVmpGLdaBV3D0E1fguaZaZ3Y5Ou9A+x4iJqkTD8za2BmP370qE1p4RZBt
yuC2LpUTaLslT6y/HJZCRlGBqfbRrZitxXopf+A3Bt25PYhq/IwRQlv/zbdeI+Cs
eLiYiU1ZHbxZziFEqFztppsTL9v90B1S785LlPX1LXfj1dVvveDw9O37FwHc1s96
ScAQq0x9JP1hcfhqCV8WokWmMjhhlnTw91LmmlqKX/7NyPvqnEbywxOCvwkm6WXV
U3gJBnJOs40OQIjd4MFC4Kvai63M0nuzMFiajW2SrvIvfiIBvi8=
=tj6D
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/6a817da9-49d0-d475-52fa-73e9b20212a3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey,

I've opened a pull request [1] to the AEM repository.

Again, enormous thank you to Rusty Bird for being a wonderful GSoC
mentor and helping me clean up the patches for submission. You are
awesome!


Cheers,
Patrik


[1] https://github.com/QubesOS/qubes-antievilmaid/pull/20
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZnDJDAAoJEFwecd8DH5rlK5IQAMKSh+6fRkOVjwVGUZoRRagv
a7GY/7kJ2T7ZCkMf6Nlv9/PEndhOa6ZGNKXbVvqv4pX1/3z1g8MngOXDTQP73OvL
pHS4WDMpZkWkTfjaK07ihpehxbggu/jOfvfUf8wyRFj1PnLn3pdsbM/BqRKdXFcc
Pr8boZ/KAE32+MUEaT4I9LcHmGn3mBxAA6hiYUGQlWKqRIiNhBL9912Fj4bjQjRk
YWh5kfigbKLx8gU5+UdfknwMMZhLDWWzk5KGZBFGIen8XJJRYPVrFLxiOxweMyxD
aTh7jTpTYVlHkdpqrq9mSz9nr//0FC3ImytFjXvZK8MH/gqrfm1y87LyUL0laSj3
QmKBc81s23xTKrLW7oSvul1M+c4M7o2pxn5puJnZJhpWya6bfz8pEu4uCRVAMu9Z
jOyIF6IWMkBVocJaaZ2lSGmgNYlCnb1DYJ0wsUQktgtSEgSzxmUdPtqBuAdQn9+g
R9zYE1dzbyyY/4od7vekMeMMWRgaGawgHeLJv+qcROi9FYHvVWh1MIX+jaCyjFn+
XE73ewrdWcbtavAP0L+ds2QVw21QFBe+ASbiIZlmvyt1n3evFdvWVdsuDv89feyF
negiOWJE1sqpK4ytA53V0oBYKwS41KZlwn8WVgrdjY4qgbvTRcRuiM92Xzd0qDXk
jqBslNFhUNybfmtLSKZv
=RKId
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/4b9875ee-2b66-c2be-d157-19a6e53043d6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/16/2017 05:51 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Rusty: do you think it's ready to be built and pushed into R4
>> testing repos?
> 
> Almost ready IMO. I have some more line comments, can you open a PR
> on my qubes-antievilmaid fork? (Just so that I'm able to insert
> comments into a flattened view of all commits.)

Done.


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZlHFLAAoJEFwecd8DH5rlUZcP/j5pwQP3qz58K7HxmRK8vntr
/5XDDSbOPESCB12Li81Cg+OTeL+Ble9G1h+okhA0KFTV7Ho8XteFc8VJq0papG4f
Fl8VUjzJHVMbkFNpiW6v3A0sQiCcKIrkWLfB2bCw57qLiJLH9DGiO5utoIJ9/UzB
Qiypi+fqoOnxwy5FwS/pZmN+m2WA0vgheqlTBs3u9Bekyy3Ev0usy4DgLBKFBbo4
BIrM5RcMUTvlqFySY/2U9xxrTMOFtrn1v/wxeWSzdEOWJp3eed30c/R5SaWObHhI
lvWRBlW/vDUsDOygThaqxi44RlFb44YV1wTnL4t4o9KE3v92MyJNygYBozW6n0RM
gPPyX9kzAp8U+u+AfCVIOY0Pat3jmKbtKsIx633Zs6Umpx3ahsXYXy0hjMwjLIm1
dXbAWxMR0xKmiqaGFTFe8mV6Vl7UL2+v61B/qGk8pIg6XVKLwJvbBB9NqpCi0MP6
3pD+OaMsA4xXV9hAXohPO61akJp+oiOaYqeeAyHDQ7CnLd9nWx1u4LrwpPjvV7cn
yO1v+FXYQIkvH3qIEtDxNV1rEXRYwU07+IVzuak6KUt4sdqLeFY98Ha5F/N+UpqJ
D81nshtPhXNkhmpE0XSMlZv6dwKAVeNCaJngn78YQRsChqFI/SUEnQKAAm6A5yoj
zxtAcs5ON9MAKa3K4tUA
=dSQp
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/0e409758-fefc-0400-21be-09104717cbeb%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

I've updated the README a bit [1] to (hopefully) make some things
clearer. Also added a section on how to recover from compromises.

Rusty: do you think it's ready to be built and pushed into R4 testing
repos?


Cheers,
Patrik


[1]
https://github.com/phagara/qubes-antievilmaid/commit/11f518fce62aa6f962b
894094ef129b86dfbc6ae
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZlEIwAAoJEFwecd8DH5rljAQQAILfYkrbnZKxbsBy3MCMtaL6
cv1ARFZuR0307aMK3HO1Xe62rjQZsgcVSaM9RfjVkqCS8MQgzpAPRgJkeQvwXg4y
eMpX/ST9muu9hgkNPcg2/x6BxViOTvS+ZChKH0H6PSxOleWx0ZPWo2C7eno/8Aib
6GRTCEsan88ElyloZLcPbDaTMrbgpo1ytFMwFcMhlgXaAL8S3sgWgKZc9QY6O1qL
Mi9Sv027ZEtKgOt11gp8p+ZPqpJpxRGaZ8EPJtLgV4vNAUOkWELieJkuOinWTe9s
qm/qJYFka9VYJg4VnODDvius6PMaZ2DzJDgY0vvkRqVqKNiD/8xNpQZHsRLfXJHD
bb19s7rGQA3BGTFoUrt747LE6eWiMmOkbOQcB238RFbn1tQLk9tFFa4X17s5yQDt
VvFHfWUflCtvcuWZP+cwJE0mZW5YMhP8STmZtxfwIi40wn2bUpgL3EZ2wQnDeHn1
Mw88vyuKRm0EKAFbwaZ3V8KaSQSsM7JUQ+Cx7zS4akBc/JNEYIzfj7+XkEb63yrB
9MPqbkdVGuuELju1K7U8VtwsrCWNxIOCtn22qa2N+XxmvtSHUFAIuWiD98OfnjMH
vEaSUL8T/6si2FaTc8thKwyqx+eeWv92Tf8fydWnSoWHtxw3fqyEv328luH9H3Zj
WqUPW6lglqGcXfAF0AJO
=dwkX
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e27a1c5f-48c7-f76d-deaf-81ffc6433aa6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/13/2017 07:28 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Finally managed to track down why unlocking disk with unsealed
>> and decrypted LUKS key file didn't work on a clean Qubes OS
>> installation.
> 
>> While starting to develop this feature, I added the key file path
>> to my /etc/crypttab and had forgotten about it. Fresh Qubes of
>> course didn't have this change. Combined with one weird systemd 
>> incompatibility (the B point in this [1] forum post), it had
>> caused the key file to get completely ignored.
> 
>> There are two ways to work around this issue [2], neither of
>> which is perfect [3]. Both solutions' downsides are pretty
>> insignificant and most likely not applicable to 99.99% of
>> existing Qubes OS installations.
> 
>> For now, I've decided to go with the second option (ignoring
>> crypttab even for hostonly dracut setups).
> 
> So, to summarize, rd.luks.key works in both hostonly and
> non-hostonly mode now, with this change? And
> rd.luks.options=discard (instead of rd.luks.allow-discards) does
> too? If so, that seems very reasonable.
> 
> Rusty
> 

Haven't tested the discard option yet as my 4.0 rc1 is on a HDD for
now but yes, that should work too.


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZkJdfAAoJEFwecd8DH5rlD8YP/2qug04xgTQzArQ/Hy1Xu9EA
Mu/eEscytBWnl19ej9VcmuZwOjfwhrAOo+LPJKJf3nETGB9Nn4TxXOyVmsjk9eod
WOaCQ6C/75HXxTD21KiiBhAOCZjiRm8fCSvFeUq7D9T/lx5hRazeWgWiDjD+6TqX
QvmPdsSwyJC3G73yDAJexF5Uii8zSj0WI3+8Crpl/xCK+TPGpjXlbeWXfmZZbEAc
JXNHel/PYKR3Rk35QmH2iFQeL3RtgzaxtIXPVhFXBhuNC0YU5xSpy8Z6A8BvSEkb
s9Ie9De1mDjO3TCdTeJorqBSX1VgsLUXnxAISy/2fq+5VcOG/fYLA2Lw2HflzFJ8
Rwx07Y0VwWHiGQb1jHTSpnPIWEXtDVAxmoSz8rdE4cNOHHyBoLEGfXBGOewsgfjG
cQhTsBpqmENDGTMrVn92ojOpS3BrlZg6vdObhZV18FS2WBXxGRxq0fdkVaBPYbZJ
eYZrw8SodjlnSMzZaTFoFvh5v8OPh4CAlIVACkS6vgn513phabeghCLVKYqOtHMW
cVm3b+JD9/y/+U+aS435U5Cw905yv/s8uclrPAv8pRBMXsC29GtDBjsPTNbrZkvF
c76GKAT5uJKho90qNM2e/iUEYxQI2ThiRLeO0tEpSEtSCkbSbzrXYzn94U/72WER
tEhlw6gWOc6zIXzPd7cv
=Kk4l
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/57d659fc-624e-fdd3-1662-df567d7d3e0f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/02/2017 07:05 PM, Patrik Hagara wrote:
> On 07/26/2017 03:21 PM, Patrik Hagara wrote:
>> On 07/25/2017 08:48 PM, Rusty Bird wrote:
>>> Patrik Hagara:
>>>> Would it be OK if I squashed all the commits so far into a 
>>>> single large one (as there's already quite a lot of reverts 
>>>> and design changes anyway).
> 
>>> Yes, please do.
> 
>> Done, along with some refactoring (plus an implementation of your
>>  RO/RW manual unplugging suggestion). Feel free to start
>> reviewing. :)
> 
> 
> Just a quick update: code review is in progress (see [1] for 
> comments), with various small changes and fixes being made [2].
> 
> 
> Cheers, Patrik
> 
> 
> [1] 
> https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d
4a
>
> 
72ec6696b621fa76e2a95
> [2] https://github.com/phagara/qubes-antievilmaid/commits/master


Finally managed to track down why unlocking disk with unsealed and
decrypted LUKS key file didn't work on a clean Qubes OS installation.

While starting to develop this feature, I added the key file path to
my /etc/crypttab and had forgotten about it. Fresh Qubes of course
didn't have this change. Combined with one weird systemd
incompatibility (the B point in this [1] forum post), it had caused
the key file to get completely ignored.

There are two ways to work around this issue [2], neither of which is
perfect [3]. Both solutions' downsides are pretty insignificant and
most likely not applicable to 99.99% of existing Qubes OS installations.

For now, I've decided to go with the second option (ignoring crypttab
even for hostonly dracut setups).

For any brave souls out there trying out Qubes 4.0 rc1 already, able
to compile their own packages using the qubes-builder and having Intel
TXT on their machines, you're welcome to try the latest commit from my
repo [4] and reporting back with any issues or comments (even unclear
documentation!).


Cheers,
Patrik



[1] https://fedoraforum.org/forum/showpost.php?p=1681988=43
[2]
https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a
72ec6696b621fa76e2a95#commitcomment-23617394
[3]
https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a
72ec6696b621fa76e2a95#commitcomment-23617493
[4] https://github.com/phagara/qubes-antievilmaid
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZj2x6AAoJEFwecd8DH5rlJnEQAI8+ouvRkXwzsz0CpN5UgOqB
1qmvua0NgBK1SC15gPeXjuOABXqO8IxJcVpuOoIL3wdZaHvvNgpGmXiKWUu6YTwi
h1yhS5w8/2rMhfLRT86AyP6H9SRwdC0DgrjCbBzsQtWZH4kBg8ItOK3q2XWrwhhC
3hckSJ4KbZNgT86q0PABCInLfDrxADiFnI+oOQBvHInq/hWuJRibDBWAnNG4AetA
KCkKpMGSSZTBzl6hBfczqtdWc/K7lIhPAO26ht87046ZRN+RjpOl588M2gsw2zYT
z3AHDQAY0+m8qAMv89luklyoYJCcg4RiMTOrPrGtBDFuHGB+rylUFDLujI+AaDH1
lLWNaPXBWUXsKBUqaHOWjP7ek+iK3Nl0yotqkngpiDZ+SNvrCCUa4xaG8j6NjVX6
jd8J/OsWzeiSDygzLKY4mitjNIT4d9yoHND4STte3UcWwAeq1vXlb4Ypvn7z7MNJ
w9ZDveawLv5Z6ZPLKMUsCml4JrGiLnK74jYi/GSMulB8ZMA2mfJGr9IAgMF8hp9b
+Aw2O0kkU3PMp5tTGgIsMAFI3nJcUN2TibiP5OA9898kVO0HXzpYFUfKhQATgjzf
g+1PIJwmO2WHvPGO1uYD0SwXyM7joXmg7z5lUEKqo40sU5nW3T/6qrpxymlP+Sy1
1AfgopK/R9mbwGrmvqgs
=SBa8
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1a5287c1-cd1c-402f-e91a-dd94e258a725%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/25/2017 08:48 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Would it be OK if I squashed all the commits so far into a
>> single large one (as there's already quite a lot of reverts and
>> design changes anyway).
> 
> Yes, please do.

Done, along with some refactoring (plus an implementation of your
RO/RW manual unplugging suggestion). Feel free to start reviewing. :)

I also took the liberty to remove Qubes 3.2 compatibility shims
(workarounds for old systemd and coreutils pkgs), so scream if you
cannot test on 4.0 yet. I'll be installing the 4.0 pre-release on a
spare drive over the weekend myself (ie. I haven't tested the current
commits yet, might be that some small bug sneaked in while refactoring).


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZeJdtAAoJEFwecd8DH5rlwaEQAK0pHY5lQLVAv3NC8uhuLsq5
1JVD7Dn6vv4z6cYL30LxcwwLkuIacWPWs92Ja+lpqUxTTcoLzByl7DVwo3E2j5d7
aJ6yKpWTnd2MBvGaC7GO/yNMQ3tDEh2uAoSPm4eRhK5aHCdqO7d6KaUnbZba8WjJ
fITscsI/whr+YSwDS3ORmVcaikefGZSliHkEw3xogc6wKzAQYCfutFMpiVCsGUAP
Qc4w7naMruuO2p3ZnS0vtNI9Blvw8nIRm8Vd9XWaS4og4b+gFCAq/HBLNhTMjcnR
hetoB0B+s2O5E6QV6Vsl6km7fMY7WKtRfciIU2Ul0cVBc9weo7cz/sRGgMDYD23K
P6HjClS3FHC+zpYm+O3tm/KRq22BLPO1a/djeoz4yPCwKmF1TrW7LiHsEsj7GtxU
DD8ThUecScftKnJ82kPQqkBW8lFcOTnkZzzvJ1UuTCvGA/qyrfRcgaIMHlwhSzxH
xBIMHn1uiRn+JIuogxmn/WFy7lfU/LW5f5VWmHjwWDYaxcjtPEDsNzs9O7g4TmTn
ZDAIqTzbr52/zQRjyeHIMsgduafcWa7xUVq9KQtBPR9AT28GhZtrIWpxCFpOwLFP
XFwDwe+Wq9szKz0lZsYB3CtJkV6Ttlz2GMfIxCjS4eh0iF/5jsthxgHiM/g7OFZp
z9hUnAWk4wSDKsXCKPA7
=dw/8
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/e6454350-38c4-a439-f5a4-a33659e800ad%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/24/2017 04:40 PM, Rusty Bird wrote:
> Hi Patrik!
> 
>> Thinking about RO/RW AEM media gave me quite a headache. We want
>> to allow creating a RO AEM media that would ignore freshness
>> tokens -- but then the attacker can trivially downgrade a seized
>> media from RW to RO and thus the freshness token hash in TPM
>> NVRAM would never get invalidated if the user doesn't notice (eg.
>> attacker flipping the switch on microSD to SD card adapter the
>> user leaves in their laptop).
> 
>> Extending a PCR with the media RO/RW status will prevent this 
>> scenario, but also make it impossible for user to create a legit
>> RO AEM media by eg. flipping a physical RO/RW switch on an SD
>> card or copying an existing USB stick to a read-only CD... Unless
>> there was a way of sealing data to arbitrary PCR values
>> regardless of the current state -- and luckily, there is! Will
>> need to write a custom tool for that since tpm-tools'
>> tpm_sealdata does not support sealing to other than current PCR
>> values.
> 
> I was wondering about RW->RO downgrades too (didn't realize you
> were already working on this part...), and came up with the
> following tweak: Currently, the unseal script will mount the
> device, do its work, and unmount. But it could be rearranged to
> mount, copy the sealed secrets to /tmp, immediately unmount, do its
> work, and at the end, check if the user removed the device. If
> that's the case, the unseal script can create a file in /run to
> skip -seal.service via "ConditionPathExists=/run/...".
> 
> This would prevent the easy downgrade, and it seems pretty
> natural, UX-wise, to remove the device early if you don't want to
> reseal. Probably much less code, too?

Not sure about how natural it would feel... I'd say the best UX for
removal of AEM media would be to _wait_ for the user to decide, ie.
print a message and wait either until the device is removed or the
user decides not to do so via a key press (_not_ a timeout). Explicit
is better than implicit, as the Python saying goes.

>> And while we're at it, why not also extend the boot device label
>> into a PCR -- what if the attacker covertly changed the label and
>> the user then used this AEM media? There's risk of DoS attack by
>> filling up the NVRAM freshness token area, or worse, overwriting
>> other AEM media's freshness token hash (thus preventing it from
>> being used).
> 
> Booting from an attacker-modified AEM device is dangerous anyway,
> e.g. there could be exploits against the ext4 filesystem driver.

Yes, but while the ext4 exploits are theoretical, the DoS I outlined
would be guaranteed to work.

> But when extending a PCR with the label is only one or two lines
> of code, why not indeed. :)
> 
>> Changes pushed
> 
> Thanks! I'll try them out later this week.

No rush, I'm still churning out small fixes.

After a code-prettifying pass though, I'd be interested in some code
review again. :)


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZdjymAAoJEFwecd8DH5rlnfYQALvJ9KfaCAHc7CCmcouFtWgl
K5XLa3h83YL4GiH+JmV6YtxjsvwewpNwZadmSpx/pemAGIK8NVUyD4VH51twNs0D
0Kqamo9y0GVOonILzR2chXRu9woyZSxq/RQhsZb6sfDZxvs6cKFkPDrcFwC9KuRk
oWS/yHGEkFxUAqgLbMKcUa+ISCDcN9UEq9XEE8b5wOVB8V+QdCKseZonTjceVvec
C952TNBp45rWoygMIM+bDvLFcudsjFpNWteL31An2fWaOyNWNuWMgDZoJF2rqQKw
zBQK17JLGQaYZsBYzGXwIjTATzB6q333mL/t9qkLLf2tvsCEszDlhkTUwGHwLSZF
DS8nJe+kudIc3KUNBtgq3GzHys2FvY07P+NBDix9IYsTKLcdnxjEwR/A9OUAMcjc
0xUnN5KJoBpwe3ABwd/xp8wj37LxlVtpZTURxglbbQ/QBCzCwrtzFbrNS0JiNi5U
PQLIGoX9YLywD3bYyT9K5IL9ZNmbisAFzWyDwHShy+OoB3X1pwhXGJL0Xphqf5oc
IuDJglOTvXsPZEfhbrvHszcKBpEhJOTrmrEp+5j8EJIbqJ90UcH8b9btIbmBVBzp
dT7OWmQDu0ORkNRtbTwek9wr///+PIM/n13MdogmTv69Cxkvtwf5BVqld7Ox0Smz
mj8MKs4dkf/ffMRvYHWg
=09sQ
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/dd7692d7-13e6-f2f2-6ee6-b55911d9e7b7%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/20/2017 03:24 AM, Patrik Hagara wrote:
> I've got most of the code written already, just need to finish the 
> -unseal script bits and test it, then I'll push it to my fork -- 
> should be in the following day or two, depending on how many bugs
> I managed to write again.

...or how many more hard-to-solve design issues I find.

Thinking about RO/RW AEM media gave me quite a headache. We want to
allow creating a RO AEM media that would ignore freshness tokens --
but then the attacker can trivially downgrade a seized media from RW
to RO and thus the freshness token hash in TPM NVRAM would never get
invalidated if the user doesn't notice (eg. attacker flipping the
switch on microSD to SD card adapter the user leaves in their laptop).

Extending a PCR with the media RO/RW status will prevent this
scenario, but also make it impossible for user to create a legit RO
AEM media by eg. flipping a physical RO/RW switch on an SD card or
copying an existing USB stick to a read-only CD... Unless there was a
way of sealing data to arbitrary PCR values regardless of the current
state -- and luckily, there is! Will need to write a custom tool for
that since tpm-tools' tpm_sealdata does not support sealing to other
than current PCR values.

And while we're at it, why not also extend the boot device label into
a PCR -- what if the attacker covertly changed the label and the user
then used this AEM media? There's risk of DoS attack by filling up the
NVRAM freshness token area, or worse, overwriting other AEM media's
freshness token hash (thus preventing it from being used).

Changes pushed, now to finally finish the unsealing script. Hopefully
I don't find any more issues.


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZdeXnAAoJEFwecd8DH5rl6R0P/2QkKp3H0edZYxnylJbqpr7C
5udtkIJgEJh+mLi4sbC8S1T24Sl9CVflK+H9a7UuTkGcV7AcM2YaPmpJzsBpqdp7
65F1MfhoDLtLQkXzg5AgBdNbIaLy1oTrinXCXOYRWoxuHqd2eHe5n0veW5iOvSjQ
2EBUJmv0/wKBYTRIH+nkAmIly1r759zSpJJi8tb0JtlwxARou45SJDYH3U//4jdi
TgclSxmx8HnJ5bGVH7dhOpShsSBKWWMLBMFRr/Acwi5rzpIpgVeAz3Wor3lXaJYo
veEbklhQnFDTQ2UYJ0FuuLdNLTATrgTOkaDb8GPLGPMbNAQdjqhGly5be/+WumPd
9lsftzJDygNpf2iyla6k+6/HeZVJ3ZeAu6aM5U8Sfawcoa0qBhMJmwP0YxZn5BV5
b2nlns9JSFMt/L6O2S0WrHnYDFQdE6bzmvNhUhS4BIbnnB5w/3BSHi5BKkB3ZEeR
4gb6SQ5ViElgiiFcjlFTEQ3MzaXTZ/ytCCunDCfOUTmXkEuZkBFz45bsKpdFklML
GbL5M2i+IrSvv0NS2f4inZn9N5W+fxY9/2852CwxRUPgPpFk3kdSSYQ2WJgm8WdU
TtEgOE+g8/eTCaxlDvv7O4UsHMgO3uYM8IfF+7dURhC4AbRLRSt59Baj615ELz6j
aL/BAfKgORG1+dqrAgzr
=aw1f
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/1bd7dbaa-c005-ff12-9085-425891100332%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #6

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/20/2017 09:08 AM, Andrew Morgan wrote:
> On 07/20/2017 12:03 AM, Andrew Morgan wrote:
>> On 07/19/2017 11:56 PM, Patrik Hagara wrote:
>>> On 07/20/2017 07:42 AM, Andrew Morgan wrote:
>>>> I'm currently trying to work out a bug where inotify_watch
>>>> calls will fail around the 8000th folder that's created or
>>>> moved in. I'm assuming this probably has to do with a limit
>>>> coded somewhere so I'm looking out for that.
>>> 
>>> Sounds like fs.inotify.max_user_watches sysctl [1] is the
>>> culprit (set to 8192 by default).
>>> 
>>> 
>>> Cheers, Patrik
>>> 
>>> 
>>> [1]
>>> 
https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limi
>>> t-reached
>>> 
>> 
>> That was it, thanks Patrik!
>> 
>> So should we just up this from the daemon or from within the
>> template? Is there any reason not to I wonder?
> 
> Ah just checked the stackoverflow source, seems as if memory is the
> only concern. We definitely don't want the daemon to be unable to
> correctly mark files, so either we set it appropriately high and/or
> warn the user when we've reached the limit.

You're welcome. :)

Yes, simply printing a warning is what I've seen programs like Dropbox
and minidlna do.

If your daemon is running with root privileges, it could modify the
sysctl itself (but it's an ugly hack). If not, adding the sysctl call
to /rw/config/rc.local would work on a per-VM basis (either manually
by user or automatically by daemon). Setting the limit globally in a
template would not waste any extra kernel memory in AppVMs that don't
make use of inotify watches (ie. don't run the daemon) and would be
the cleanest option IMO. And it could even be done via a post-install
scriptlet of your new package.


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZcFpXAAoJEFwecd8DH5rlmM4QAI6PGHnpaG/MR6UkEd02152N
WXCeODX6JjxfxTzAf64ll3eitdATJT+g3yU0E4XEj+qa8DzfPgMwDFrnOPXMQuK6
NIEqBib4yoy6OgQ7e9i2ns8k4qy5dVM8547hnAVVQsD3p4ruJi/AOyKeDFZJlreq
n2nubxm15LviMNw6mIq5ktYUY1+Xr0Zi4hziwcrezgwmyfuYs9D2OSCyQWLjUQFz
WdByy1vYJYEU0y9BdgoRGo4l+At4DuBNClamgvTOFtuD4U7psdu1SQcpMR3wGHdm
Tm23fvMEfsvsQwjckJS3dq9QWJY6pKcHaOCfnNYzM0dD7bHhKfAvL8xUapgSFc+3
cWBiwyv1Z0OxZV9Obw/wBeSGzIgrboZH0nMNZecoeYc79+V39NV4zZ2iGJNECr1/
DDUExU7jPwfmexce2rGwUCm02CCl6+EvScpaG2kyU6YgjkpiA5AZ7F4uxm5yRw3N
gDZ1cVeOvv/pyUAm0igDVQyGNFBLbQWOf0hyLz7soP1SNOA+LUKK2IGcc1osONQ0
QgwhJHgYxkBPPzVEzcEIKWOEAgQkfNUi7SI/Uqstq3gUApw+Yz9PDHXUWyOJnqsj
PpVVSp4GCLSxMQRvcFZZJmY/FuWXND0fXjMU2eVSS37Lw5qopd79/K9lAp/1ZKWl
VzLx5sgHu2myl4K+KwOJ
=dZQs
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c382b8bc-b2a5-6d31-c0dd-9cf922a0e8ff%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #6

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/20/2017 07:42 AM, Andrew Morgan wrote:
> I'm currently trying to work out a bug where inotify_watch calls
> will fail around the 8000th folder that's created or moved in. I'm
> assuming this probably has to do with a limit coded somewhere so
> I'm looking out for that.

Sounds like fs.inotify.max_user_watches sysctl [1] is the culprit (set
to 8192 by default).


Cheers,
Patrik


[1]
https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limi
t-reached
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZcFQ1AAoJEFwecd8DH5rlNmEQAIbO/LfURLkToAf64mnAULbZ
IN+sKg+1H/w6Jx7cQvA/GmNk+2av1lxOG9R9mmQR+JbH/DEtBCaY3rjWVEDvmeVf
uMTE9qo8SYA9b74xN1H/HaNG1q9+0ChxNmyi055yyVqElz5q2TaQ0TrpuK2jdvvx
4Cdo8voRvpI7iUG+TNDAajX7OJie5DreKjSNBAmSF4hGM2ppgGCtcLke1to6buAi
R8Nj7iCLqAvbM79tdw2rOpnUn5ZVKDaa4r/tpnM8MM755zZlmTUAP17uFm+iSZU4
WZZQ9sQy13IxpPmiBDt8QAvgqlzwVWcN1CTFBCM9PO5PFJxAktWhU/8azuAVNHdF
+tGDNktj9RWsjtdd9OdnLHlnlAulYymoKMu+V6ZSFgSqYxcYPF8KD2UPRjUbxMzh
wjOpaW9Xu8C1jFB5nVL/ls6Argh89VyU8FbahC3w9wJc6vnd8Sd7BJp/qpFrnmE+
utV86OECDYMCMYq8L9CVIOIzO5/WTVW773H8ZxmGTGIGXYTY5WHllnQq4w8IB38E
2xeFG2PrhYppR+xZ60yoENEkQAJEFeunzAh2y54KVNo9d0YMA/KWqWxaZbAv8d3Z
hKxM5qMzbt/sBkyR/iYe2For1Qc7NYPQ8ODPQ+RlgnXyHwLWpXjKrDAOhsIg+puX
TqDnEhYVVRPjiBJGgQ7f
=/f9Z
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c2cbc26d-9be5-e6ff-0122-6e59ee19c146%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

First off, sorry for the delayed report this week! I was doing
"drawing board" work almost exclusively for the past ~three weeks
trying to wrap my head around all the outstanding issues and figuring
out some decent avenues for fixing them, so there was no code
committed and I felt like there was simply nothing "real" to report.
My mentor, Rusty, has encouraged me to write something up anyway, so
here goes. :)

First, there's the annoying problem of needing to (preferably
non-interactively) reset the TPM dictionary attack lock while having
an owner password set to not-well-known value. Although I've been able
to find a way of substantially reducing the number of "triggering" TPM
calls (by replacing tpm_id's tpm_getpubek call with a custom randomly
generated TPM ID stored in NVRAM), there still remain the incorrect
SRK password guesses while probing whether SRK password is set or not.

While the reduced amount of DA lock trips might work out just fine
under normal usage, the backup plan is to store TPM owner password on
the encrypted root partition and perform a DA lock reset after each
successful boot (eg. from the -seal script, which should now get
called every time due to the new "freshness tokens" discussed below).

Freshness tokens are the means of preventing an attacker who gains
access to a (copy of) AEM boot media _and_ who knows all the required
passwords but cannot gain access to the Qubes computer right away for
some reason. In such case, the user has a chance to either forcibly
invalidate the stolen AEM media and thus preventing attacker from
unlocking the encrypted computer (provided the user knows the AEM
media was stolen from them/copied); or, if they are not aware of the
fact that the attacker possesses a _copy of_ (since a missing primary
AEM stick would be pretty obvious) the particular AEM media they use
to boot Qubes on a regular basis, they can still (unknowingly) stop
the attacker in their tracks by simply rebooting often enough...

Another issue is the need of mapping particular AEM media to their
respective freshness token hash "slots" stored in the TPM NVRAM. I
decided to make this a simple AEM media label suffix to slot index
mapping, stored on the encrypted drive. This approach has the
advantage of easily replacing lost/destroyed AEM media (or perhaps
even read-only but outdated, but I haven't figured that one out yet)
- -- simply anti-evil-maid-install to a new media using the same label
and answer yes to the prompt warning you of the overwrite (the old
media will automagically become unusable).

As for storing the actual freshness token hashes in TPM NVRAM, for now
I'm planning to make it a fixed 8-slot memory area (much like LUKS key
slots) and addressing individual slots using offsets, since I've read
[1] that each NVRAM index definition wastes and extra 93 bytes of
overhead. Even Chrome OS decided to use just 2 NVRAM indices [2],
presumably due to the same reason (since you cannot set different
permissions for portions of a single index definition and they needed
that for the firmware/kernel spaces).

I've got most of the code written already, just need to finish the
- -unseal script bits and test it, then I'll push it to my fork --
should be in the following day or two, depending on how many bugs I
managed to write again.


Cheers,
Patrik


[1] (p. 37) https://www.cylab.cmu.edu/tiw/slides/challener-TPM.pdf
[2] https://www.chromium.org/developers/design-documents/tpm-usage
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZcAZRAAoJEFwecd8DH5rlY3UP/iKmN2zKmYyj4oIfHpbFTUGt
HmaEAtGU1PE1OrplB3bE9jTuY/8TvE3uQHMoCN4YaV//Oho79k8a3DtUWOitZwkR
bhUXyNjH2kFTX8Ckd+/pUvtNrzubj5Uj05TM1PG8KLIUjk0dgWmm11fk5LxektCq
d1KtGg5RrbStB/1/kcllm3SMVzQVhWXu4TgfMt/8HZ2xBqpuTarJQZNcRqfAIQHw
AONPtiQX8B15+V7brtJwRJE8WKrR+5NxDjtjaFEoTuM5g1AxLJ1aNj+cunYRR8LM
M3eZjVzPRFhbBMu+dvs8ML4seV4PdcWdmU/MkOhYJ6yc+WesliNPZXZ8Bkq4PZeQ
Kcfhl8/h+dMXeTzNUvWc7GJCl5tj1ycdJR1mxPbL8k1a7EsP9G+4n3XYpNYAg6XV
5XcenUNDngLUbf6mZWzk58j90DMBqns+DZrrOiVDmSoF2QW9WaiTdtxn5kPAbziL
jBAvXN3vvYgIlfB1dq6ZqYgoumHyGmY9dytMrde0En9eI7T4qbouuD8kg1Ve0UIP
3sOAzw//+ebumQdC8lGEA0OUjFI90d4bduqUdvo0EoFJ0OhYGAHySzZ3b7F/tXRB
UvuR9T/D/cOqluMbJ1Cqe7eVjdizhJbKo8sQsaUy8elkIBMAYVZED+UeqCsji1Tm
ecp6spib2RcvYcDtpZa1
=QM3b
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/c425fb59-48c7-251c-95d8-11756436329c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/05/2017 05:30 PM, Rusty Bird wrote:
> Patrik Hagara:
>> On 07/04/2017 12:28 AM, Rusty Bird wrote:
>>> Hi Patrik!
>>>> OK, let's go with the freshness token then.
>>> 
>>> To avoid implementation complexity here: What do you think
>>> about unconditionally requiring the freshness token in all AEM
>>> setups, and (as a stretch goal) skipping the token _update_,
>>> both on the AEM medium and in NVRAM, if the medium is
>>> read-only? IMO it's not crucial to implement this read-only
>>> check in AEM 4.0.
> 
>> Hmm, that could work.
> 
> How should portable Qubes installations be handled? We can't save
> the owner password in the initramfs. But I was thinking, the
> function to write a 256 bit value to NVRAM (at index n) can be used
> to store not only the hashed freshness tokens for every AEM device
> (at index 1, 2, 3, ...), but also a randomly generated TPM
> identifier (at index 0) that could actually replace all the
> tpm_getpubek stuff in tpm_id.

Assuming "portable Qubes installation" means sharing a storage media
containing installed Qubes OS between multiple machines -- we could
store a TPM (UU)ID to {owner,NVRAM} password mapping on the portable
encrypted root disk instead of a single password; plus per-machine
(per-TPM, rather) sealed AEM secrets (which in the current
implementation would get mixed up and overwrite each other if TPM has
owner password set up, but otherwise works already -- simply replacing
tpm_id with something not relying on pubEK will fix this, more below).

Neither the owner password nor the NVRAM area password are stored in
the initramfs, as that would be a security risk. They are stored only
on the encrypted root partition.

The TPM 1.2 spec mandates at least 512 bytes of NVRAM storage to be
available (actual storage is vendor-specific, no upper bound given).
Assuming 20 bytes per (sha1) hash that's only 25 values in the worst
case -- and this space is shared between all "applications", so Qubes
AEM should probably not take up all of it.

So far I've thought about storing a unique 20-byte value as a TPM
identifier (a randomly generated UUID hashed with sha1) and reserving
a few (say 2 or 4) 20-byte slots for freshness tokens, so that you
could have MFA-protected backup AEM stick(s). That's just 60-100
bytes. In principle similar to LUKS key slots stored in its header
(which has space for 8 keys).

What do you think?


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZY5qsAAoJEFwecd8DH5rl6CUQAKuGo5KScXV11eXLJWVmHcf5
1ZO75U/Sx3nLnmbz4Crzr5ci0UpLMbIVnum+Aq82oou93la7NEX4EMhCaTQsILP3
tTVnPPw/hz8OSRptb1zV0RRFU243VvB5zmrVLvT8g/G0lfnTVmFhb448L/+WYB33
dw/V11e+JKfriG2ahnRRuK7yICXYsxz6TOiB7ZULbP0jMMB2b7W7VhC/5Pz51OzE
t0voS9K12NaRaARBjDA9f13XEkjzkbSA/LtA71PG3nzUpE+W8HUKFn6g800HnaE2
bWYf6O6lumRUyrqcHj425jpMu/vGlePH9FSiOTBm3BMuHjLPlHKOUkkVpukPMKUf
feXoVRX+aA2EmDLYFKac8myTz7hu6+k2UEP+zDH6B2RPTgHIe3xvANMi3ZL5cSf0
aLm9mwk/NtCoyibjtqZ3wDlmFGpVfYB/FqNiQNBN/x272OfAcNkInV9tFb7v173b
JYOp445v3/Oq8kvlc3Lrqhueqfv7o4AzFIuMWQsyYDvehiB4uVPbfInGAGWyoqgW
pLbMOo1pT0BJXaN+B9q9UwLmxZm7d1qJ7ZKuH1N/n71EIJ6qis+76V+2rppdPnhV
+7LVMK9pJQDSUw9isbIA5TSmq9WCcUqJLrtlY6zUC0kZqSQQY7pMxm8Mic4bIqqo
OlLYPgAXileuu7S0yp2j
=X/Y8
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b0402595-5c15-777e-51a0-53ae255d3fdf%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


0x031F9AE5.asc
Description: application/pgp-keys


0x031F9AE5.asc.sig
Description: PGP signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/04/2017 12:28 AM, Rusty Bird wrote:
> Hi Patrik!
> 
> I just noticed that qubes-devel seems to break your PGP/MIME 
> signatures. Inline PGP works better on Google Groups based mailing 
> lists. (The CCs have all been fine, of course.)

Thanks for letting me know! Hopefully fixed now.

>> On 06/26/2017 05:28 PM, Rusty Bird wrote:
>> I guess your last point is valid, we can seal the actual
>> secrets (txt/png/keyfile) just once and always reseal
>> only the "freshness" token. I'll have to think more about
>> this, but so far I didn't find any obvious flaw with this
>> approach.
> 
>> As for the DMA attack mentioned in your later e-mail,
>> shouldn't the IOMMU (which is required for Qubes 4.0)
>> automatically protect against that (as it gets activated
>> by Xen)?
> 
> I might totally have the wrong picture here, but can't the
> rogue PCI device (which would not be assigned to any VM)
> access all of dom0's memory? [2] Or are there more
> fine-grained restrictions?
>>> 
 You're probably right. In which case, encrypting the whole
 (not just dom0) RAM would most likely be the only option.
>>> 
 Considering the ability of DMA to modify memory, unsealing
 the "freshness" token before the actual secrets would not
 provide any meaningful security and the resulting AEM code
 would be pretty similar in size anyway. :(
>>> 
>>> Reading memory (with a DMA attack, a cold boot attack on
>>> transplanted RAM modules, or a cold boot attack in the same
>>> system if SCLEAN really doesn't wipe all memory) still seems
>>> like it could sometimes be more straightforward than writing
>>> memory (with a DMA attack). And it's kind of neat to be able to
>>> protect text secrets, in the absence of these memory attacks.
>>> 
>>> I don't know. But we can always revisit the whole separate
>>> freshness secret thing later. Maybe somebody will weigh in on
>>> read-only media support in the meantime?
> 
>> OK, let's go with the freshness token then.
> 
> To avoid implementation complexity here: What do you think about 
> unconditionally requiring the freshness token in all AEM setups,
> and (as a stretch goal) skipping the token _update_, both on the
> AEM medium and in NVRAM, if the medium is read-only? IMO it's not
> crucial to implement this read-only check in AEM 4.0.

Hmm, that could work.

 One significant issue I've encountered this week is that the
 TPM dictionary attack lock actually triggers after a few
 reboots (due to tpm_id and tpm_resetdalock calls with
 well-known owner secret)...
>>> 
>>> Would removing the 'tpm_resetdalock -z' calls in -unseal and
>>> tpm_z_srk improve the situation? Looks like it's
>>> counter-productive in setups with an owner password.
> 
>> There's also the tcsd_changer_identify scripts with call to
>> tpm_id which gets executed every time the tcsd service is
>> starting (via ExecStartPre tcsd.service unit drop-in). The
>> tcsd_changer_migrate drop-in will also call tcsd_changer_identify
>> itself if not already migrated. That's one or two tpm_id calls
>> which contribute to dictionary attack lock. And I see no way to
>> get rid of this completely. :-\
> 
>>  Anyway, why should having a non-zero owner password
>> prevent you, a local user, from reading the TPM's public
>> endorsement key? TCG claims it's due to anonymity concerns (as
>> the pubEK uniquely identifies the TPM), but the same can be done
>> by querying (via /sys or whatever) the serial number of any other
>> HW component (mobo, HDD, battery, ...) or just the specific HW
>> configuration/topology (model numbers, which bus/port the devices
>> are connected to, etc.). It makes sense for remote attestation 
>> (and the spec already has a Direct Anonymous Attestation protocol
>> to solve this) but not much for local usage. 
> 
>>> Also, -seal could avoid the tpm_z_srk call if $CACHE_DIR
>>> exists, and in this case set $Z based on whether
>>> $SRK_PASSWORD_CACHE exists.
> 
>> Yeah, I'd rather just call tpm_resetdalock here with a password
>> read from the (now unlocked) disk...
> 
> Sounds good.
> 
>>> If it turns out to be necessary, TPM utilities can read from
>>> stdin -- but only when /dev/tty is inaccessible (like in a
>>> systemd context):
>>> 
>>> # mv /dev/tty{,.bak}; echo password | tpm_whatever; mv
>>> /dev/tty{.bak,}
> 
>> That's... not nice.
> 
> I forgot to mention that this line is only for testing!
> 
> Inside of the anti-evil-maid-(un)seal.service systemd units,
> /dev/tty is already inaccessible, so 'echo password | tpm_whatever'
> should work. (When the anti-evil-maid-seal script is invoked
> manually, the 'echo password' input will be ignored and
> tpm_whatever will display its own prompt.) See e.g. the
> tpm_sealdata commands in the (un)sealing code.

Oh, right! Somehow I missed this fact (/dev/tty inaccessible in
services). Still, the workflow outlined right below is 

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/19/2017 12:43 PM, Rusty Bird wrote:
> Patrik Hagara:
>> On 06/18/2017 05:51 PM, Rusty Bird wrote:
>>> Rusty Bird:
>>>> Patrik Hagara:
>>>>> Single-use key file code committed
>>>
>>>> Whee, I finally get it... Seeing how it all fits together, it looks
>>>> really cool!
>>>
>>>> What do you think about making replay protection a self-contained
>>>> secret? If we'd change it from a counter (shared between the combined
>>>> counter+keyfile secret and NVRAM) to a per-boot random string stored
>>>> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
>>>> hash_ -- then AFAICT the attacker still wouldn't be able to malleate
>>>> the secret in any meaningful way, and:
>>>
>>>> - secret.fresh.sealed (the first to be unsealed) could be used to
>>>>   replay-protect all types of AEM secrets, not just keyfiles
>>>
>>>> - If secret.fresh.sealed is in fact stale, the keyfile would never
>>>>   have to be unsealed into memory, where it's susceptible to a cold
>>>>   boot attack (probably even if the tmpfs file is shredded, due to
>>>>   buffers)
>>>
>>>> - It seems like this approach should simplify the implementation? No
>>>>   concat/split code, fewer special cases (e.g. all AEM setups would
>>>>   have the same always-reseal workflow)
>>>
>>> Hmm, replay protection would be incompatible with the use case in
>>> which a backup AEM stick is stashed away somewhere. So it probably
>>> shouldn't be enabled in non-MFA setups after all, or at least not
>>> unconditionally.
> 
>> Anti-replay secrets could be compatible even with backup AEM sticks,
>> just by having separate secrets for each AEM device.
> 
> Oh, right! NVRAM has enough space.
> 
>> However, always resealing would not work for read-only media.
> 
> And read-only media could theoretically become more attractive in R4, if
> hypervisor vulnerabilities (=> updates => resealing) are going to affect
> Qubes less frequently.
> 
> OTOH, making replay protection _optional_ would complicate the code yet
> again. For example, tagging a particular text secret as "don't display
> if secret.fresh.sealed is missing", similar to the current counter +
> keyfile concatenation.
> 
> :/
> 
>> For cold boot attacks, a good solution would be to encrypt the whole
>> memory using eg. TRESOR (storing encryption key in CPU debug registers),
>> with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as
>> most/all Intel processors with VT-d also have AES-NI. Not sure whether
>> encrypting RAM from Linux would be enough or whether we would need to
>> implement the encryption in earlier boot stage (tboot or Xen).
> 
> There's an old ticket [1] for TRESOR -- targeting disk encryption keys
> only, but even that is "far in the future"...

I've read some more about Intel TXT and tboot... and it seems that cold
boot attacks could be ruled out as any abrupt shutdown will trigger a
secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM
module). However, I'm not 100% sure whether whole RAM gets wiped or just
the TXT-related bits -- couldn't find that explicitly stated in neither
TXT nor tboot docs. :-\

And since the BIOS ACM is a binary blob, the only way to find out will
be to actually perform a cold boot attack...

>> I guess your last point is valid, we can seal the actual secrets
>> (txt/png/keyfile) just once and always reseal only the "freshness"
>> token. I'll have to think more about this, but so far I didn't find any
>> obvious flaw with this approach.
> 
>> As for the DMA attack mentioned in your later e-mail, shouldn't the
>> IOMMU (which is required for Qubes 4.0) automatically protect against
>> that (as it gets activated by Xen)?
> 
> I might totally have the wrong picture here, but can't the rogue PCI
> device (which would not be assigned to any VM) access all of dom0's
> memory? [2] Or are there more fine-grained restrictions?

You're probably right. In which case, encrypting the whole (not just
dom0) RAM would most likely be the only option.

Considering the ability of DMA to modify memory, unsealing the
"freshness" token before the actual secrets would not provide any
meaningful security and the resulting AEM code would be pretty similar
in size anyway. :(


One significant issue I've encountered this week is that the TPM
dictionary attack lock actually triggers after a few reboots (due to
tpm_id and tpm_resetdalock calls with well-known owner secret)... This
can be solved by storing t

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/18/2017 05:51 PM, Rusty Bird wrote:
> Rusty Bird:
>> Patrik Hagara:
>>> Single-use key file code committed
> 
>> Whee, I finally get it... Seeing how it all fits together, it looks
>> really cool!
> 
>> What do you think about making replay protection a self-contained
>> secret? If we'd change it from a counter (shared between the combined
>> counter+keyfile secret and NVRAM) to a per-boot random string stored
>> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
>> hash_ -- then AFAICT the attacker still wouldn't be able to malleate
>> the secret in any meaningful way, and:
> 
>> - secret.fresh.sealed (the first to be unsealed) could be used to
>>   replay-protect all types of AEM secrets, not just keyfiles
> 
>> - If secret.fresh.sealed is in fact stale, the keyfile would never
>>   have to be unsealed into memory, where it's susceptible to a cold
>>   boot attack (probably even if the tmpfs file is shredded, due to
>>   buffers)
> 
>> - It seems like this approach should simplify the implementation? No
>>   concat/split code, fewer special cases (e.g. all AEM setups would
>>   have the same always-reseal workflow)
> 
> Hmm, replay protection would be incompatible with the use case in
> which a backup AEM stick is stashed away somewhere. So it probably
> shouldn't be enabled in non-MFA setups after all, or at least not
> unconditionally.

Anti-replay secrets could be compatible even with backup AEM sticks,
just by having separate secrets for each AEM device. However, always
resealing would not work for read-only media.

For cold boot attacks, a good solution would be to encrypt the whole
memory using eg. TRESOR (storing encryption key in CPU debug registers),
with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as
most/all Intel processors with VT-d also have AES-NI. Not sure whether
encrypting RAM from Linux would be enough or whether we would need to
implement the encryption in earlier boot stage (tboot or Xen).

I guess your last point is valid, we can seal the actual secrets
(txt/png/keyfile) just once and always reseal only the "freshness"
token. I'll have to think more about this, but so far I didn't find any
obvious flaw with this approach.

As for the DMA attack mentioned in your later e-mail, shouldn't the
IOMMU (which is required for Qubes 4.0) automatically protect against
that (as it gets activated by Xen)?


Cheers,
Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/18f570e7-10c4-e2f8-bcbd-89aac4834cdf%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/16/2017 09:32 PM, Patrik Hagara wrote:
> I will push those changes to my fork after
> some cleanup and a re-test (most likely tomorrow).

Single-use key file code committed [0] and I'm going to check whether
clearing the TPM invalidates PCR-sealed data or not. If it does, then
generating an extra signing key will not be needed.


-- Patrik


[0]
https://github.com/phagara/qubes-antievilmaid/commit/4b398390b5335222c6d6a9799df3230755fc8d4b


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/74a6ff0d-1ce7-f36b-6059-64bcca886bca%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/13/2017 12:45 AM, Patrik Hagara wrote:
> Unfortunately, it seems monotonic counters are designed to only be
> manipulated (create/increment/destroy) by the OS and thus the TrouSerS
> project chose not to provide any APIs to perform those operations. This
> trousers-users mailing list thread [0] contains additional information
> (details the limitations), posted by the late Hal Finney.
> 
> Given that information and the fact that Linux does not currently make
> any use of the available TPM monotonic counter facility and neither does
> it expose any TPM-backed virtual counters to the user-space, I've been
> thinking whether it would be possible (and secure) to use TPM NVRAM
> instead of a proper monotonic counter -- eg. allowing writes to the
> NVRAM area (to increment the "counter") only if a correct authorization
> key is provided (stored on the LUKS-encrypted root partition), but
> otherwise being freely readable (protected only by the optional & in
> this threat model useless SRK passphrase).

I found out that implementing a secure counter in NVRAM would require
having a TPM owner password set -- otherwise an attacker can simply
undefine and create a new NVRAM area with chosen counter value -- while
the owner password is currently assumed to be well-known (ie. "not
used") for dictionary attack lock reset and reading the TPM public
endorsement key.

This might not be an issue, since the TPM pubEK is used only by the
tpm_id script for creating per-TPM directory on AEM media; and the
dictionary attack lockdown requires multiple incorrect password entries
in a short period of time to trigger (at least for the particular TPM I
have available).

Still, an attacker with physical access could perform a full TPM reset
(without knowing the existing owner password, by using the "physical
presence" authorization) and then create a new counter in NVRAM with a
chosen value... And since we do not want to prompt the user for TPM
owner password during boot (risk of snooping) _and_ the attacker is
assumed to possess a full copy of the AEM stick _and_ knows all
passwords used during a typical MFA AEM boot, they can successfully
unseal, decrypt and use the LUKS key file. :(

However, I think an extra signing key can be generated inside the TPM
and used to sign the counter value (with the corresponding public key
stored on AEM stick _and_ measured into a PCR). This signing key should
then get wiped from the TPM if the attacker performs a reset.

I already have a PoC for the above (except the signing key pair for TPM
reset attack) with a world-readable 4-byte counter stored in NVRAM that
requires an authorization password for writes (this pw is stored on the
encrypted root partition, counter gets auto-incremented on each AEM boot
and key file re-generated). I will push those changes to my fork after
some cleanup and a re-test (most likely tomorrow). Should someone figure
out any other way to circumvent this, please let me know. :)


-- Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/37db3ce0-dc1d-3a4f-be5f-68832158346b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/10/2017 08:10 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Any and all code reviews are welcome! The changes I made are stored in
>> my fork of AEM repository [1].
> 
> - Please don't feel obligated to read this on a weekend :) -

:)

> One thing I noticed is that a comment in anti-evil-maid-unseal
> mentions setting up /tmp/keyfile in /etc/crypttab. But adding the
> kernel command line parameter "rd.luks.key=/tmp/keyfile" to
> /etc/grub.d/19_linux_xen_tboot would have the advantage of working
> even if dracut is in no-hostonly mode (e.g. on portable Qubes
> installations), where /etc/crypttab is ignored.

Yes, this would be the better solution, thanks!


Cheers,
Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/b3d9442c-42de-ec3e-9f34-133e51eb3020%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSOC] Extended File Attributes not preserved by most editors

[Patrik Hagara]

On 06/10/2017 05:47 AM, Andrew Morgan wrote:
> Another way to mark files is to just list and later read their
> filepaths, line-by-line. However if one is marking a folder of thousands
> of files as untrusted, that tracking file can quickly become very long.
> Perhaps a database option would suffice, do any of our tools use a
> database already? I'd like to keep these efficient as possible without
> harming the UX.

How about using a DB (I'm not sure whether qubesdb would yield
reasonable performance, but SQLite should work just fine for VM-local
stuff) and monitoring files/folders via the inotify [0] API to keep
track of new files created in untrusted folders, files getting
deleted/renamed and generally avoiding race conditions?

The API even provides events for extended attribute changes, so you
could, theoretically, reapply them when discarded by text editors.
However, this would likely result in more race-y behavior.

One possible solution might be to create a FUSE [1] stub file system
driver that would proxy all the FS commands to a real driver (eg. ext4),
but discard (refuse with EPERM or similar error) all calls violating the
"only use in dispVM" per-file/folder policy as listed in its database.

Alternatively, it may be possible to use SELinux [2] object tags for
Mandatory Access Control (MAC) -- which should be, compared to extended
file attributes, sticky -- and write a policy that would refuse to let
those files be open()'ed. This approach would IMO work the best, as it
should (presumably, since SELinux is security-oriented) avoid all race
conditions. Plus, I'd imagine it would be easier to code than a custom
stub FUSE FS driver.


Cheers,
Patrik


[0] https://linux.die.net/man/7/inotify
[1] https://en.wikipedia.org/wiki/Filesystem_in_Userspace
[2] https://selinuxproject.org/page/Main_Page

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/f1bb704d-096a-bd1a-64d2-4e1db5f85223%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/09/2017 05:22 AM, Rusty Bird wrote:
> Rusty Bird:
>> In the current WIP version, the keyfile is encrypted before sealing
>> and decrypted after unsealing. (Using scrypt - if we trusted the TPM
>> to handle the raw keyfile, we could just use SRK password protection
>> instead.)
> 
> Sorry, I have to retract the part that says SRK password protection
> for the keyfile is (in theory) an alternative: The SRK password
> applies to the unseal operation for the TOTP secret as well, so the
> user has to enter it before they know that the computer is in a good
> state. But then the attack Patrik pointed out as the motivation for
> adding TOTP in the first place would still succeed.

I think using a SRK passphrase is irrelevant in this scenario.

Say the attacker managed to compromise the computer so that it always
boots attacker-controlled kernel. User gets prompted for the SRk
passphrase and complies, but the TPM will fail to unseal anything since
the PCRs wouldn't match -- ie. no correct TOTP code displayed.

The same would be true even if the well-known SKR (ie. no passphrase)
was used (which is, to my knowledge, already considered secure paired
with removable AEM devices). And it would have better UX -- one less
(near-useless, in this case) passphrase to remember/type.

However, it is true that the attacker will have the ability to copy
contents of the real AEM stick and on subsequent evil maid attack will
be able to unseal both the TOTP seed and encrypted LUKS key file -- and,
assuming they also managed to snoop the key file encryption passphrase,
will gain access to the encrypted drive.

Compared to a scenario in which TOTP is not used, the one described here
has one, albeit small, advantage -- if the user is fully confident that
nobody has _ever_ had the chance of snooping on their LUKS key file
passphrase, they can simply stop using the existing key file and
provision a brand new one.

I am not sure whether leveraging the TPM's existing monotonic counter
can avoid the problem, since there seems to be no TPM facility to unseal
a blob if and only if a counter value sealed along with it matches the
TPM's internal counter value _and_ unconditionally increment the counter
should unsealing succeed -- this would (unless I made a mistake
somewhere) fully prevent key file replay attacks and force the attacker
to use the captured AEM media contents _immediately_, before the user
notices and artificially increments the TPM counter (rendering the
captured data useless) or simply performs a normal AEM boot (even if
unaware of the ongoing attack).

Such feature probably could be implemented in software, since it's code
would affect a PCR and thus the sealing key. Hmm...


Cheers,
Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5bca42ec-1666-2beb-a4a8-a24a3a755aab%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/08/2017 03:48 PM, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
>> On Thu, Jun 08, 2017 at 11:19:22AM +0200, Patrik Hagara wrote:
>>> How about storing the key file itself inside the TPM? This may (or may
>>> not) open some new possibilities while, apparently, not extending the
>>> attack surface since the raw LUKS key file already passes through the
>>> TPM before being encrypted by the user.
> 
> Wait, what? Does this refer to a hypothetical change to AEM? In the
> current WIP version, the keyfile is encrypted before sealing and
> decrypted after unsealing. (Using scrypt - if we trusted the TPM to
> handle the raw keyfile, we could just use SRK password protection
> instead.)

Oh right, sorry for the mistake -- the key file is indeed first
encrypted and only then passed through TPM for sealing.

>> AFAIK there is very little storage inside TPM and it have even more
>> limited write count than standard flash memory. Also, for this to work,
>> it would require that TPM allow you to access the key only when you boot
>> valid OS - so, not only seal (encrypt) the key to PCR values, but also
>> make it condition to read some NVRAM part. AFAIR such thing isn't
>> supported - you can only protect some parts of NVRAM with SRK.
>> So this probably will not work.
> 
>>> Should the TPM not be trusted enough to handle disk encryption key
>>> material, then _two_ user encryption passphrases would be required in
>>> order to prevent TPM from learning the LUKS key file contents while
>>> still attesting the correct machine state by being able to unseal it --
>>> ie. enc(seal(enc(keyfile))).
> 
>> If we don't trust TPM here, the whole AEM makes very little sense...
>> Note that malicious TPM may not only steal values sent to it, but also
>> lie about PCR values, effectively making you enter valid passphrase into
>> superseded password prompt.
> 
> If I understand it right and sending the raw (or brute forcable)
> keyfile to the TPM is being considered, IMO we should urgently avoid
> that. Of course a malicious or exploitable TPM can be used to mount an
> evil maid attack, but trusting the TPM with the keyfile aggravates a
> probably much more common threat: For example, any computer acquired
> during a regular search and seizure, and then possibly lying around in
> an evidence locker for a few years anyway, could be decrypted as soon
> as forensics finds a way to peek into the TPM.

Yes, that sounds like a realistic threat and should be avoided.


Cheers,
Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/49fed906-36f0-4ab0-0f00-442caaee5c10%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/08/2017 01:56 PM, Marek Marczykowski-Górecki wrote:>>>  - if
someone copy AEM stick _before_ observing proper successful boot,
>>>he/she can replay it, because copy of AEM will still have "old" OTP
>>>valid (a keyfile encrypted with it)
> 
>> This weakness is impossible to prevent in every scenario I have been
>> able to think of so far. :( The upside is that the attacker will need to
>> posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_
>> gain physical access to the computer -- essentially adding one more
>> factor (possessing AEM boot files) compared to the existing implementation.
> 
> _IF_ monotonic counter in TPM can be used also to seal something, then
> it should be possible to mitigate this attack too: once you advance such
> counter, you will not be able to unseal key sealed to the old one.
> But this will only work if such operation is possible with TPM (I don't
> know).

Yes, the Trusted Computing Group's TPM specification version 1.2 (not
1.1, however) does mandate at least four 32-bit monotonic counter to be
available, with enough storage endurance to survive at least 7 years of
counter increments every 5 seconds. See the "Part 1 - Design Principles"
document [0], section 17 "Monotonic Counter".

However, while both the tpm_tis kernel driver and TrouSerS user-space
library (along with tpm-tools) claim to support TPM 1.2 spec, I was
unable to find any reference to monotonic counters in either (though
maybe I just wasn't looking hard enough).


>>> Some of it may be possible to improve using monotonic counter from TPM
>>> (I assume there is something like this). Maybe some
>>> challenge-response could be performed here (after authenticating machine
>>> to the user), with usage of TPM monotonic counter, instead of "just" OTP?
> 
>> How about storing the key file itself inside the TPM? This may (or may
>> not) open some new possibilities while, apparently, not extending the
>> attack surface since the raw LUKS key file already passes through the
>> TPM before being encrypted by the user.
> 
> AFAIK there is very little storage inside TPM and it have even more
> limited write count than standard flash memory. Also, for this to work,
> it would require that TPM allow you to access the key only when you boot
> valid OS - so, not only seal (encrypt) the key to PCR values, but also
> make it condition to read some NVRAM part. AFAIR such thing isn't
> supported - you can only protect some parts of NVRAM with SRK.
> So this probably will not work.

I'll look into this.


>> Should the TPM not be trusted enough to handle disk encryption key
>> material, then _two_ user encryption passphrases would be required in
>> order to prevent TPM from learning the LUKS key file contents while
>> still attesting the correct machine state by being able to unseal it --
>> ie. enc(seal(enc(keyfile))).
> 
> If we don't trust TPM here, the whole AEM makes very little sense...
> Note that malicious TPM may not only steal values sent to it, but also
> lie about PCR values, effectively making you enter valid passphrase into
> superseded password prompt.

Of course, you're right.


Cheers,
Patrik


[0] https://trustedcomputinggroup.org/tpm-main-specification/

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/8662acf1-bd37-4202-c7dd-f5399d8f5b1c%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/08/2017 12:45 AM, Marek Marczykowski-Górecki wrote:> I was
thinking for some time about a scheme where user enters
> also something dynamic - OTP (not necessary TOTP) - either in addition
> to normal passphrase or, instead of. But it's tricky how to do it
> properly.
> One idea is to have LUKS keyfile encrypted with the next OTP (in
> addition to other protections like being sealed to PCR values of TPM).
> And after successful user authentication, prepare it for the next boot
> (since you have access to decrypted disk now, you can access OTP key to
> generate next OTP). In practice probably not just one encrypted keyfile,
> but few of them (like 5) using consecutive OTPs to allow some window if
> you accidentally press a button on OTP token (or a button in mobile
> app).
> This idea have at least few weaknesses:
>  - each boot require some write on AEM media, which means a) it can't be
>read-only, b) in case of flash it will reduce its lifetime (to make
>password really one-time, already used encrypted keyfiles should be
>wiped - probably using shred or sth like this)

A few notes regarding this point:
  ad a) the boot-time sealing script already expects AEM media to be
writable if secrets fail to unseal, does it not?
  ad b) wiping one-time key files might prove problematic with
(unencrypted) flash media due to their wear-leveling algorithms.


>  - if someone copy AEM stick _before_ observing proper successful boot,
>he/she can replay it, because copy of AEM will still have "old" OTP
>valid (a keyfile encrypted with it)

This weakness is impossible to prevent in every scenario I have been
able to think of so far. :( The upside is that the attacker will need to
posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_
gain physical access to the computer -- essentially adding one more
factor (possessing AEM boot files) compared to the existing implementation.


>  - similar to the above - it is not resistant against brute-force
>attack; 6 digit code (or even 8) is not so long, even if you force
>reboot every few tries and somehow prevent offline cracking (dumping
>unsealed but still encrypted LUKS keyfile from RAM)
>  - the boot procedure more and more rely on security of some additional
>device
> 
> Some of it may be possible to improve using monotonic counter from TPM
> (I assume there is something like this). Maybe some
> challenge-response could be performed here (after authenticating machine
> to the user), with usage of TPM monotonic counter, instead of "just" OTP?

How about storing the key file itself inside the TPM? This may (or may
not) open some new possibilities while, apparently, not extending the
attack surface since the raw LUKS key file already passes through the
TPM before being encrypted by the user.

Should the TPM not be trusted enough to handle disk encryption key
material, then _two_ user encryption passphrases would be required in
order to prevent TPM from learning the LUKS key file contents while
still attesting the correct machine state by being able to unseal it --
ie. enc(seal(enc(keyfile))).

What are your thoughts on this?


Cheers,
Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/3e416333-1cd5-b8a1-ecd3-1c20a6de0d2b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

On 06/07/2017 09:45 PM, Rusty Bird wrote:
> Hi Patrik,
> 
> Sorry that it took me a while to respond to your first "offical" :)
> progress report. This email has some general stuff, but I'll post more
> here or on GitHub later this week.
> 
>> Right now, I would say the first version of my code changes is almost
>> finished.
> 
> I'll summarize part of my mental image of this first version (also for
> the benefit of casual readers), please correct me if it's wrong.
> 
> There are now two new AEM setups: Setup A has TOTP and encrypted
> keyfile secrets on the only AEM stick; setup B has TOTP and fallback
> text/image secrets on a primary, and the encryted keyfile secret on a
> secondary AEM stick.

Yes, that is correct.


> (Is there any attack where a TOTP secret adds additional security i> setup A? 
> If not, it should only be done for setup B, right?)

One possible attack scenario I thought of is for an evil maid attacker
to configure the machine to disregard user's AEM boot device and instead
boot attacker-controlled kernel. This kernel would then pretend to have
successfully unsealed the LUKS key file -- the user has no way of
knowing and will thus enter the key file passphrase, which would
subsequently get captured for the attacker (along with a copy AEM boot
stick contents).

Now the user would have to immediately and completely destroy their
computer, even if they are sure nobody has _seen_ them typing the
passphrase. I would consider this to be a regression from status quo.

With the additional usage of TOTP, this kind of attack will be apparent
to the user (wrong TOTP code => do not enter key file passphrase).

The attacker can still, of course, learn the key file passphrase via an
observation attack and then seize the AEM stick -- but this is true even
for both the "setup B" with two sticks (which would always be carried by
the user together, ie. no added complexity to the seizure process) and
current "plain" AEM setup.


> But given setup B's very subtle security benefits [1] and tough UX -
> now that its (necessary) complexity of implementation has been proven,
> which I severely underestimated, I keep agonising if your original,
> simpler proposal would be the better trade-off after all...  Somehow I
> had focussed too much on the time setup B would take to implement
> (which seemed okay as a stretch goal), and not enough on the
> substantial increase in tricky code paths that future developers
> working on AEM will have to understand. With probably even more to
> come, e.g. fallback support when the secondary stick is not at hand,
> or other corner cases that tend to turn up in testing. Not to mention
> the user-facing things like documentation and usage messages

Yes, the code got fairly complex pretty quickly. And there is still
number of cases my code does not cover yet (plus a few bugs I found in
the meantime). :-\


> I'm mortified to ask you this so late, but what do you think about
> scrapping the setup B and TOTP related parts? And considering them
> research showing that your original design approach was tasteful and
> mine was overly complicated. Or am I too squeamish about the amount of
> code?
> 
> (CCing Marek, who ultimately decides what goes into the AEM repo, to
> see if he has an opinion on this issue.)

Personally, I would be OK with abandoning the two sticks scenario (but
keeping TOTP as written above). I would say it was a worthwhile
experiment that just fell short on both UX and security (due to code
complexity) and, as you stated, would be hard for future developers to
understand/maintain. Also, I would imagine users would have a hard time
comprehending the resulting lengthy documentation, even if well-written.

I am eager to hear Marek's thoughts on this issue you brought up.

Thank you for the feedback! :)


Cheers,
Patrik

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/55e683f5-a7c4-3ef4-7585-c477a74350b4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] [GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

Hi!

As some of you may already know, I have been accepted into the Google
Summer of Code program to work on improving Qubes' Anti Evil Maid suite
to provide resistance against shoulder surfing and/or video
surveillance. The project proposal I submitted can be found archived on
this (qubes-devel) mailing list or in my GitHub repository [0].

It looks like I have managed to just slightly overestimate the time
needed to write the code for all the additional features and options for
AEM package. :)

Right now, I would say the first version of my code changes is almost
finished. Small bugs here and there are to be expected, but unless my
mentor (Rusty Bird) or anyone else has objections, I would consider the
new AEM workflow to be finalized.

Any and all code reviews are welcome! The changes I made are stored in
my fork of AEM repository [1].

For now, the next steps I am planning are to:
  * verify all the added features work as intended (lots of reboots)
  * check for any regressions (even more rebooting)
  * document the new AEM setup, upgrade and usage procedures

Again, I would love to hear feedback -- and not just from my mentor! ;)


Cheers,
Patrik



[0] https://github.com/phagara/gsoc2017-qubes-aem-proposal/releases
[1] https://github.com/phagara/qubes-antievilmaid

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/42dad15d-58e2-75ce-f8f4-a1cebee32f74%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-devel] Re: Request for feedback: 4.9 Kernel

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Jun 1, 2017 at 2:55 PM, Pablo Di Noto  wrote:
> Hello,
>
>> 1) Hardware that used to work with 4.4 or 4.8 no longer works with 4.9.
>
> Using it on a Lenovo X250 (i3-5010U), and other desktops.
>
> Experiencing consistently the "no wifi after resume" which was working fine 
> with 4.4.x

This can be avoided by adding "iwldvm iwlwifi" line to
the following file in your WiFi NetVM:
  /rw/config/suspend-module-blacklist

>> 4) General feedback on the 4.9 kernel.
>
> Oh, yeah... I have started experiencing quite annoying internet connectivity 
> issues, very, very difficulty to troubleshot. Symptoms are:
>
> - Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never 
> reaching some of the content.
> - SSH sessions can hang while exchanging keys, and if the recover can last 
> for hours.
> - Pinging sys-net from sys-firewall sometimes stops responding, but that does 
> not happen consistently with the higher level issues (browsing from any VM 
> can be impossible, and still ping works)
>
> After 4 days of troubleshooting (switching browser versions, browser brands, 
> changing templates, replacing openwrt+mwan3 home router with direct 
> connections from ISP demarc to the machine, using different ISPs, doing all 
> the same on a brand new R3.2 + "--enablerepo=qubes*testing", creating new 
> sys-net+sys-firewall based on different templates, and so on...) y have just 
> found that taking a failing setup and setting the kernels of all involved VMs 
> to 4.4.67-12 makes the problem disappear.
>
> It seems pretty repeatable, and would love to provide debugging info, 
> although I do not know where to look for.

I, too, encountered this issue and was unable to find
the cause. Had to revert to 4.4.67-12 kernel. :(


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZMBWaAAoJEFwecd8DH5rl770P/3pKQQaOvDil2NVOy9Id5UWt
7nQ5FmY2gflcHpVnKZP4i7aczEsekd675v+LtoNUVNGvuW+6D5Ytz8mrGtADUz+E
NOI4fFoL/aRw7Xi7aeWseYhsIMOoRbD4S60edMxsTzrlVMjvsg/lo9LrhRVt3wNm
FoQZbXJoshByy+vsAJ/lbqIck0O8yYCbnLh1EMmHtbbol9uIrkSHHgzL9R2LGef/
IqFqhUemqAx8TtGe4WuczU8JOHNSQaMcKEUngkxhfhcPrUwWiwzygwpMPPax6fPE
Omqo5WeMl2zcsHv2bcbObVSzTyBuiLaH+iB07IWf9qCTCCjzgq84lvbMhWB/p07+
tx+4kYfNrWujzcg8BvSVgRUv7wX++q1j1oBQKZKwyi8RZRwFZa4+CybxWsaa3iof
/BsSs+I8j7hJ7uUi+zEfKvBnvnhLAHQ+tDTXZSS4D6gAltCmTFpM78YR/uNLTCWt
eZ2Ep8OT/2RbUbLRAP7CZ8Gkhc9T1v/8SK7WkbT6qWNOkMjJvMMcnj+ShcIntt9A
QV4MIUNKcIKDbV16CFhcOldPvv6ry09EMZ3HhQJM83CxPtsVc26GUDd64pkJueC/
voIN391r7gv81d3MsrDfx2fE0lZUV+baMaWWrF6jf0EuoyDwXXoqipnoByTxVMUm
1YYLBsylBtHXKWSJeoPb
=aqNW
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAFfni-FgXVL9xKit2Cg2WfY%3DrVYpf4j1_-j3CeMs77f2thhSBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] ipv6 for internal network in 4.x?

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, May 29, 2017 at 4:45 PM, Peter Todd  wrote:
> On Sun, May 28, 2017 at 05:46:22AM -0700, pixel fairy wrote:
>> > Are you suggesting that VM's no longer have internal ipv4 addresses? You
>> > mean
>> > via the ipv4-in-ipv6 address range or something else?
>>
>> i was thinking dual stack and nat for both 4 and 6. my first thought was
>> using the v6 addresses to internally address the vms, but that seems to be
>> mostly done through vchan. proxy, firewall, and network vms, would need to
>> support both anyway.
>>
>> the only other way ive tried was nat64, and i remember hitting a problem
>> with tls verification, but my setup could have been wrong. tried googling
>> for "nat64 ssl" and "nat64 tls" and cant find anything on it.
>
> Right, with nat64 you're requiring the VM's and the software in them to use
> IPv6 addresses, which get translated to IPv4. That's inevitably going to have
> compatibility issues, as nat64 just isn't very common, and there's plenty of
> software around that can only talk IPv4. I think a dual-stack arrangement is
> much preferable to this, even if both IPv4 and IPv6 end up having to use NAT.
>
> It's notable how the relative rarity of IPv6 NAT may be a problem - the IPv6
> infrastructure wasn't designed with clients running multiple VM's at a time in
> mind.

I'd like to mention the relative complexity of the IPv6 specification
(and by extension, its implementations) as a reason against this
proposed change. For example, take a look at this list of CVEs
related to IPv6 [0]. Please also note that writing firewall rules
for IPv6 can be quite challenging at times.

Second, IPv6 was, in fact, designed with clients running multiple VMs
at a time in mind -- you're just supposed to delegate v6 addresses
from a /64 (or bigger) IPv6 prefix and not use a NAT mechanism.

While I do accept the fact that IPv6 support is neccessary, I don't
think the existing v6 network stack implementations are quite as
mature as the v4 ones (which have undergone extensive testing "in
production" over the last few decades) -- especially not mature
enough for use in a security-oriented OS.

Should you find yourself in an environment with only v6 connectivity,
having IPv6 stack available **only** in the untrusted net VM will
definitely come in handy, but IMO all the VMs downstream should be
using v4 (either via 4in6 [1] or similar transition mechanism).


Cheers,
Patrik



[0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipv6
[1] https://en.wikipedia.org/wiki/4in6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZLFKpAAoJEFwecd8DH5rl+QYP/3s9SmOPrKlPcO8FKFIIAWfW
+RMB4PRvj1uT2sfsuMHVJhLu0RWS0ZHo1Y2yatad10fC/r9hqq7j1WbHz6+9keMJ
9vdLV1jTbuGLaEqgDNM0DPapXNau1SA4qLbEs7EgkZKv0prBLysTLXUOMwEE9zzi
T7V23fQx/un4+qiH7qmuPBgoGspyJwo7Vb0bXmrFGPNYS4Y7+YCWay4t+gI77Bcq
Ynv0OkPLpf1CWO8MnYg0S4YRikxbRJr5Sk6UeJeB2RAW0fEGtirXLJ/Kc953Je+h
lHBiRGGW1nOrcw8PR4ZLe8h7nhGtcCJK5PkktLO/SZPrrCXEYRvb9e4FFX/FG4iQ
yILLE00LPwKGX4x2wr4G53JY6cGg9cUVX960CZzZaFp2Q5sTZiFT9BVT/jBMCCXV
TCPp9O/wRyIUtJufmSWPp0UjQvUefNR2FLNg4/gH357pyqOIu0+cP3EwYL77nyIJ
hbrEo9Vv5qL3NhE9oytgBJGf75OK87KGhvqgh4maUfZFOqyC+U5mTrnc7pcwapF0
1v5XZvX35uuHEj+AR+MSOrJmu1IVG3LexHbwmxGEqAQGYVav+oCZQwMb/JjuWZwC
zwiCZhpsbcoQ0fF6nJAT5skNShQDPVtGytKe4R3x39VSg3ngbNQe2CWhKnlpx6W8
T7jTwz0TSEdmo0I5fqoS
=WsSS
-END PGP SIGNATURE-

On Mon, May 29, 2017 at 4:45 PM, Peter Todd  wrote:
> On Sun, May 28, 2017 at 05:46:22AM -0700, pixel fairy wrote:
>>
>>
>> >
>> > Are you suggesting that VM's no longer have internal ipv4 addresses? You
>> > mean
>> > via the ipv4-in-ipv6 address range or something else?
>> >
>>
>> i was thinking dual stack and nat for both 4 and 6. my first thought was
>> using the v6 addresses to internally address the vms, but that seems to be
>> mostly done through vchan. proxy, firewall, and network vms, would need to
>> support both anyway.
>>
>> the only other way ive tried was nat64, and i remember hitting a problem
>> with tls verification, but my setup could have been wrong. tried googling
>> for "nat64 ssl" and "nat64 tls" and cant find anything on it.
>
> Right, with nat64 you're requiring the VM's and the software in them to use
> IPv6 addresses, which get translated to IPv4. That's inevitably going to have
> compatibility issues, as nat64 just isn't very common, and there's plenty of
> software around that can only talk IPv4. I think a dual-stack arrangement is
> much preferable to this, even if both IPv4 and IPv6 end up having to use NAT.
>
> It's notable how the relative rarity of IPv6 NAT may be a problem - the IPv6
> infrastructure wasn't designed with clients running multiple VM's at a time in
> mind.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> You received this message because you are subscribed to the Google Groups 
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email 

Re: [qubes-devel] GSoC 2017: Community Bonding Period

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, May 16, 2017 at 03:32:41PM +0200, Marek Marczykowski-Górecki wrote:
> Unfortunately, as new GSoC org, we didn't get as many slots as we
> requested, so we were forced to reject some, even good proposals.

Ah well. I hope you get more and more slots in the
coming years -- Qubes definitely deserves a lot more
"attention" (and mainstream adoption) than it's getting.

> > Due to this, I decided to start working on my actual
> > GSoC project instead (I hope it's not discouraged),
>
> Yes, that's fine. If you finish early, we can always extend the project
> ;)

Assuming it keeps going this smoothly and I get to
finish even the TOTP token auth stretch goal, then
sure. :)

> > Is there a preferred way of dealing with forked repos
> > under qubes-builder? Right now I've simply added a new
> > remote for the antievilmaid component and I'm assuming
> > simply running `make prepare-merge` and subsequently
> > `make do-merge` should do the trick when the upstream
> > repo has new, non-conflicting commits.
>
> Yes, exactly.

Alright.

> > As far as RPM package signing goes -- I guess it's not
> > even worth setting that up for development since the
> > only person installing the pkgs built by me would be
> > just myself, in which case the signature would serve
> > no practical purpose. Am I right?
>
> If you install packages on the same machine as you build them, then yes.
> But if you transfer them using some untrusted channel (network or such),
> signing may be useful. All you need for that is to have some key
> generated, and adjust builder.conf: SIGN_KEY=, NO_SIGN=0.

Same machine, yeah.

I tried to set up split-GPG signing but couldn't get
it working and eventually decided to skip it since
there would be no benefit in my case, anyway.

Now, after a fair bit of debugging, I found out it
was simply a silly typo -- writing the RPM macro
config to `~/.rpmmacro` instead of `~/.rpmmacros`.

All that's needed now is to `rpm --import` my public
key in dom0 and I can start verifying my own RPMs.
Too bad I only have one Qubes machine. :)

> Pro tip: if you work on a single component (or some subset of them), you
> can adjust COMPONENTS in builder.conf to include only what you need. It
> will make things a lot faster.

Yes, I was building just the AEM component pkgs,
although with `make antievilmaid` (and now even
`make sign-antievilmaid`). ;)


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZGxEMAAoJEFwecd8DH5rlL2gP/RhMSgoqcIT2tjlUDOjAif3u
vgLuSwZy31EKsJquq13IxESo+WMb2Yozw43L58jIauNKPNZ3GvoEMhDkul0wMxzo
8SsatfIJCcoUkeulX+jqKtL3zwWw+Pl2C1HJzcQJ7xDK60L3ozjawIwSt7SJiPQp
Wmb9S9iVkQRA+5SIIYrqWRr+Vf01FT8q9kDYJ5KkmEEpFlCwTAMb23NbduNQ9Rf1
B6r9ed5C9Nxr1nZOvpSP2JCJgyYyysl7P2UrIWf9xhR9Th0TcumAb3/cjSZBkSud
wBodYyNSD1qwMPSIYxa/D8uuLJkmdOWHl8zCCqVH4ybfE2Gakpk5VKSYF4f21yBo
ZIXSBqks0jV14xZAGjm00/nX9ad3/O18jBzIpskd6MFAk14zAsm5bRSvGHKJAsye
0wdUxuhLRitDznNokkWGB6tJ2VRvC/ZtZLghxxSV6o5ScDUkqZu82Zyd0GzI6gpu
N8C6jui5K0FQ6EMX+kjy5II9WxVc0XWvwauEZnqI8SZnWu2KkIgrC5xRYUrlymcl
d7WZPGxF5ngK/OHKvpAnX47CS9qxOsEiVsPdMw0vzjNApHfBnAi/zQn2OioFWOy5
pHmjqd0G7CL5WUcW7a27KYUrz56LbpVvesaqTfgPW6MqR20TwOILX73c73UbxX36
ooGF7tR26q2VmL8lKURH
=g1jD
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAFfni-Fb0kxZ3n0R1q5YWTVec6yLTkrfCGJxHsU8m6nArg_pRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] GSoC 2017: Community Bonding Period

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

First off, thanks to whoever was responsible for me
being accepted into the GSoC program and congrats
to both Andrew and Paras for getting in, too! :)

On Fri, May 05, 2017 at 08:27:34AM -0700, John Casey wrote:
> Unfortunately, my Qubes project wasn't accepted

John, sorry to hear your Qubes Manager proposal wasn't
accepted. It really could use a generous dose of (not
only) UI changes.

So... I've spend the last few days setting up my dev
env and getting familiar with qubes-builder.

While skimming through issues on GitHub labeled as
"minor" and "help wanted", searching for something
quick and easy just to get a hang of the dev workflow,
I haven't stumbled upon anything "right up my alley".

Due to this, I decided to start working on my actual
GSoC project instead (I hope it's not discouraged),
implementing the first step as outlined in my project
proposal -- the AEM install script is now able to
generate, enroll and encrypt a LUKS key file and the
sealing script then seals (duh) and copies it to the
AEM media.

You can find my fork of the AEM repo on GitHub under
phagara.

Now to my questions. :)

Is there a preferred way of dealing with forked repos
under qubes-builder? Right now I've simply added a new
remote for the antievilmaid component and I'm assuming
simply running `make prepare-merge` and subsequently
`make do-merge` should do the trick when the upstream
repo has new, non-conflicting commits.

As far as RPM package signing goes -- I guess it's not
even worth setting that up for development since the
only person installing the pkgs built by me would be
just myself, in which case the signature would serve
no practical purpose. Am I right?


Cheers,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZGusaAAoJEFwecd8DH5rlTFsQALtCO7EtmRWh6sDPlN2BOVdX
lq9h1g4hc3GMvAkWaDEUItrU6Sszu8Oh7dicUuV9PD73sJ6WG+XaLOIbYlVxnaAv
ZG149jZjTXmnh04kjMyM86WPoSrlJjmT+4bov/eafmwTKkDyMtv9sX9mzyfRixdm
kNW2sJgL+RviEUwUrYYJi4oTd2c/PgeBiwZjhyyeb0VeEj7diwNdHDdJQj+pymU2
G4wtcsFQV6+EAwtI8qa580xYRcaSNUVE5RhYl3Tz4GG55KoWgHFWdfM9UiXaHrxD
2syRtgL8M2myiQnrJu092LDQOTuYa98v4H6gj42IAiGK3STP+egyJFQOkK7pqdlE
wv2qRO66RBl9UfkbT+fShBli1eOkjrhXsgqCO/LKI6zWzDEbxVsRD89haWlPCTg9
DlZUWi64HQmqrdwbjTl6XEN24Etq6EYu94pfVOE0agAnyTLHMHBc+oZoPgeTam3O
5oHlrtXNi6qJc+pNgIFaP+Fh8x1KDftnXTT12GBja2Cf5MPv6aE8n5r6WquMJpwz
6peONSzMwkOGk69v8xl/oOtPE/csPxKu8GedeDeJzHkYRKyeY1k6Hs+IgKZOxkk+
tcB2sJRXdblVdn19p72/n01GFUpbTDWOQzDJ3zrV+96nO9vCH4I7PlJAn/447hOy
T0bT2XFcyee8tJN4BqDm
=zm3L
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAFfni-GGs%2BF2kVUE5GDNhCKJvpfYtbrv0jh2EFWk5xt%2B%3DJuK0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-devel] GSoC Anti Evil Maid improvement project

[Patrik Hagara]

e

* May 30 - June 6 (one week)
  * research
* generating and enrolling a LUKS key file
* passphrase-protecting the LUKS key file
* TPM-sealing of the LUKS key file
  * implement
* proof of concept (PoC) for generating, enrolling, encrypting and sealing
  a LUKS key file

* June 6 - June 13 (one week)
  * integrate
* merge the above PoC into AEM installer, rebuild the package and test

* June 13 - June 27 (two weeks)
  * implement
* PoC for disk unlocking using a TPM-sealed, passphrase-protected LUKS key
  file
  * research
* how to integrate the unlocking PoC into Dracut initrd and Plymouth
  * integrate
* merge the above PoC into AEM, rebuild the package and test
  * evaluation
* first evaluation starts

* June 27 - July 4 (one week)
  * implement
* fallback options
  * evaluation
* first evaluation ends
  * integrate
* merge the fallback option changes into AEM package, rebuild and test

* July 4 - July 11 (one week)
  * document
* enrollment and upgrade procedures
  * integrate
* rebuild the AEM package to include documentation

* July 11 - July 18 (one week)
  * review
* engage the community in reviewing both the documentation and code
  * test
* engage the community in testing the implementation
  * fix
* documentation and implementation bug fixing

* July 18 - July 24 (six days)
  * implement
* PoC for generating/importing TOTP seed
* PoC for transferring generated TOTP seed into 2FA device
* PoC for TPM-sealing TOTP seed and generating codes

* July 24 - July 28 (four days)
  * second evaluation period

* July 28 - August 4 (one week)
  * implement
* fallback options for TOTP
* displaying and refreshing the TOTP code on Plymouth boot screen
  * integrate
* merge the TOTP PoCs into AEM package, rebuild, test

* August 4 - August 11 (one week)
  * implement
* support for secondary AEM device holding LUKS key file
  * integrate
* merge the above support into the AEM package, rebuild, test

* August 11 - August 21 (10 days)
  * implement
* fallback options
  * integrate
* merge fallback options into the AEM package, rebuild, test
  * document
* enrollment and upgrade steps

* August 21 onward (after the GSoC work period)
  * review
* engage community in reviewing documentation and code
  * test
* engage community in testing the implementation
  * fix
* documentation and implementation bug fixing

Although currently having a twenty hours per week internship, I am confident
I will be able to dedicate another thirty to forty hours per week to GSoC, as
that would be roughly equal to my schedule during the school year. However,
should this be deemed a concern, I could suspend my internship for the three
month GSoC working period. No other commitments scheduled during the relevant
time frame.

I will be sending progress updates to the qubes-devel mailing list, plus weekly
formal summaries.


# About me

Second year undergraduate in Information Security at the Faculty of Electrical
Engineering and Communication, Brno University of Technology. Previously
studied Computer Networks and Communication for two academic years at the
Faculty of Informatics, Masaryk University.

Passionate about free and open-source software, computer security and digital
privacy. Started coding at the age of twelve, presently focusing on Python.

Almost four years of quality engineering internship at Red Hat. Comfortable
working both independently and as part of a team, large code bases are fine,
too. Management distance of eight time zones has never been an issue, neither
has the fact of not being a native English speaker.

Not submitting GSoC proposal to any other participating organization.

Living in Brno, Czech Republic (UTC+2 / CEST).

Contact information:
  * name: Patrik Hagara
  * e-mail: patriha...@gmail.com
  * GPG: 09AFE672 E513B8A3 ED35643B 5C1E71DF 031F9AE5
  * [GitHub][3] and [LinkedIn][4]


[0]: https://www.qubes-os.org/gsoc/
[1]: https://github.com/QubesOS/qubes-issues
[2]: https://github.com/QubesOS/qubes-issues/issues/1979
[3]: https://github.com/phagara
[4]: https://www.linkedin.com/in/patrikhagara
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI5BAEBCAAjBQJY4Q2QHBx4aGFnYXIwMEBzdHVkLmZlZWMudnV0YnIuY3oACgkQ
XB5x3wMfmuUUJQ//WlgOlGl3XKNjCk9NtB5A2nz+tEr2Bfdh/ifXAL4Yq+BCQY9H
hAOLCbGb7YJb/8Vrp9BG6thkDhwTC9XfYgiDI6nZ/na5LJeNbz0vV91XNr6ePE3n
5M8qAYXiI6d+UMdj3yL+xLVPQns2pLWk6ppK+BjixxuugFfJwclRs9B7ao12Gu9F
2S30aFbuMXJ1MMRCorejngD/n5Fh6yATNU8HqzgEoGNRaAFjerSMB0inaFiYEKmG
4FVCuG9IRLUZOMgvC7ZmctCb4Za7gprjvcC/Np108G/qvtED93jedKv4FjyKJV+w
Gv+PFdRsiA2ly1sGH041cuPcb4C8YJxYHV/smdCePobadw+UYkNnEZ5EuQcEBbHM
IjU/nKbfCpcmA71czHbBLuPnxcNRmrjShST2thoc4RgjorUoH+zC7SI0AtRIeE1l
IxM+3ffX3wDuAc1/1Kd7mgmAUPlQAwQ8JRZTb7szb0N63pOp2oewpD7tR5McQtpS
fFuvNC6kERc0kMiKGohJDAbTaGhsRjjW+d3IxhySyM8zzcFRbqojTw0V27GOJg70
mf7ZiBCUwdA0WR7HpjTbUpGzyQ8yWIys4wBH+RNA8/9PeMFrHg/k1LTEbIQM+85N
oQFkhRhkM+oHinBIBKagHQbEakOy8ALaiUlV

Re: [qubes-devel] GSoC Anti Evil Maid improvement project

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Mar 29, 2017 at 1:39 PM, Rusty Bird  wrote:
>>> In case you deem the probability of software-based (but requiring prior
>>> physical access) multi-stage evil maid attacks much higher than
>>> hardware-based ones, I could implement both schemes (probably not in the
>>> two month time-frame of the GSoC, but I could work on it in my free time
>>> before and/or after GSoC).
>>
>> Hmm, what do the people on this list think about the TOTP device + two
>> sticks scheme? Is the small amount of added protection against multi
>> stage attacks even worth the added complexity?
>
> Since nobody on the list seems to have strong feelings about the issue,
> concentrating on the simpler scheme during GSoC sounds good to me.

Alright, I'll start drafting a GSoC proposal with the simpler scheme.

> (Please keep in mind it's impossible to guarantee in advance that the
> project will be accepted. It depends on the strength of your final
> written proposal, and on the number of student slots assigned by
> Google.)

Yes, I am aware of that possibility.

> If you do get around to starting on the complex scheme before/during/
> afterwards, then feel free to do it in any order - but the following
> might be a good progression to familiarize yourself with the AEM code
> base:
>
> 1. The TOTP part of the complex scheme. This would be nicely straight-
>forward, I think.

Agreed. I even saw an implementation [0] of this (seemingly targeted at
dracut initramfs) with a fork [1] by the Heads [1] project. The limitations
mentioned in readme are not applicable to Qubes (except the malicious
firmware remark, ofc), as Qubes already uses tboot to also measure
initramfs. If not already a no-op, it should take very little effort to
make it compatible with Qubes.

> 2. The simple scheme. Getting systemd/dracut to dynamically use a
>keyfile could possibly turn out to be a bit of a PITA.

Could be, won't know until I try though.

> 3. The decryption stick part of the complex scheme, reusing code from
>(2).

Had I not found the TOTP attestation code, I'd probably move step #1 to
the end as it requires figuring out the Plymouth UI in addition to the
actual implementation "guts". However, assuming the existing TOTP code
can be trivially re-used, I do side with the ordering you proposed.


[0] https://github.com/mjg59/tpmtotp
[1] https://github.com/osresearch/tpmtotp
[2] https://trmm.net/Heads
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI5BAEBCAAjBQJY27iJHBx4aGFnYXIwMEBzdHVkLmZlZWMudnV0YnIuY3oACgkQ
XB5x3wMfmuXY8g/9FcZ45dj4NLeCy8B07W7OAupcS5lxnoSHHR4Qp44RerCTr276
nqk2eHrVT8+TUhjAzkX544IR6qVZjkMaQh7/oCCFFMYKZEtq3TAUMCUfipmj9l5+
RipDk8AHQFAwAeqDp/i22pxdaGEpRCOY3O/xB1JIBTEPy9Kcvygs1LHU0j/4qIjv
kmBHbeNDuPDZ7KVlCzti4Ld/AmpS3JJjF2/G4mnxcOoicgbGPw8Pu0g1rkdrX+i5
p1BzBgMyXAGqnSWmjoeQlSQLRE9sajuWmMj+1si/iBaEhEvu2Y316qC/6DbxUTcw
ZxP1ApaG3/zia+T66vgcy4ukCbIx65K60dgBuCYYTjFcuTQ7dyVeqB8+aoCubxlW
w2BmyKX3ZNSCkSPoVFuLpIZ8sSmKwTylqZIirEB9sLgaIU3mHcGBHR2h7/Mn3fdA
pRx7XLB838bywThO8buAhKVkQUkdiwW1qF34cSCYQ2evQKTocu7dqdRop6gTWMv/
B0a1LNsMxxoboJXrAD5+F4GKWLLKM+7wIlKxMcd99O+OoFGe60NX4fnvxi0ZtX1I
CI6V/DkJVOlV3QHt6YWmT3cOkeJm8hHZPt9hc0teVc2KYGEzRcBIKBjerxduYMU3
cw8X8WWmeRDc+lMTCiPS8NIxu2MVnIiWNeK3n1b7We/dNBHOtjxUX9pzdWg=
=WzXB
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAFfni-FYeUYyzVKVokaVD-9N-vcWu-A2a9%3D9G7YMxRjaAL4aew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-devel] GSoC Anti Evil Maid improvement project

[Patrik Hagara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

I'm thinking about applying to the GSoC program and working on
the Anti Evil Maid shoulder surfing and video surveillance
resistance project idea.

However, I've got a question regarding the proposed
solution which requires implementing both TOTP based
machine-to-user two factor authentication mechanism and
support for secondary AEM device containing passphrase
protected LUKS keyfile (so the user has to carry two
USB sticks and a TOTP token with them at all times).

Wouldn't it be sufficiently secure to use only one external
AEM device containing both the AEM protected boot partition
and a TPM-sealed LUKS keyfile? This approach would protect
against keyboard sniffing as no passphrases need entering
(the LUKS keyfile can optionally be protected by an additional
passphrase, a TPM SRK passphrase would not add any extra
security with an external AEM device, and the BIOS boot
passphrase can still be sniffed by the attacker anyway);
screen sniffing is also prevented by getting rid of the static
AEM secret displayed upon successful unsealing, which would
get replaced by LUKS keyfile unsealing. Such set up would
successfully and automatically boot the OS from enrypted drive
only if the TPM PCRs are able to unseal the LUKS keyfile.

The advantages of this approach compared to the proposed
solution are: no need of always carrying and protecting three
separate 2FA devices (AEM boot stick, AEM keyfile stick and a
TOTP token), no manual verification by the user is necessary,
no sensitive data knowing which an attacker would be able to
defeat the AEM trust model are displayed on screen or typed on
keyboard.

To defeat the protection offered by this solution, an attacker
would need to clone or seize the user's AEM stick (and possibly
also sniff up to three additional passphrases used, namely one
used for extra encryption of TPM-sealed LUKS keyfile, BIOS boot
and TPM SRK passphrase).

If I made a silly mistake somewhere, please do correct me.


Regards,
Patrik
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQI5BAEBCAAjBQJY17VsHBx4aGFnYXIwMEBzdHVkLmZlZWMudnV0YnIuY3oACgkQ
XB5x3wMfmuUTjg/+NBOe/46B0tipScF3GW8ojHKpQWO7CYeImd+Go5jZ0BbNu9e3
HR3j5xGkUaj0nq3miDPh5jH6Qwr7IC1UfeGf1fYdfgs5V990LnQXnb9CjPokI2wo
30ZNllIQ20/fLguE56anFRGvxfjV5MiydJF2skkBYQnPNT1x7iGbFvdnVwLJ7U1l
XRemyYk1/4FimL2lbvsrbA1XTVc1hP81IjAfkiOj1rzaXPSlhdjiYigmkiiizEBb
6omo4evz9n701ApHkxwBDgu4dzZIEhHoUzXDhcuSKptYB+5mRMkm8xtguZen+zp/
iY11Ihnu3uRLhKpOWrL4/mQtnz2d9yL1J/5PMQNbIenvzBtNZCxuyhxw/1HwAxUJ
MRK+qtrFvgM/+01RJeRemoEBLcTs3CdPyezGzI6D04AgTBGpKNGDOqEsxKj3wrtf
489y/qI2ooP6UzuCvV2BavubAAodE72dID2ZLzGuF77RsqJE59MTOsEdY17/hcRl
FEEhzlel7Zg6LO2cv/lSpROFe6B1rpcf2PYBW8yA0FAzS2d7Xm1sJoHxjkKagJp7
ZryVv+w3fm8WTKsXSOicTCTwPjNsqnQ5Zaml3zu8yc1zdthagTbg5C+3+FgwbnqJ
JFrGyZBKi97OUS4245/TXfbWL6miXFSWYma8o1MlBbqEMVNaLzgGckhHP5o=
=fn7o
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/CAFfni-GRmR37FZuvxPCctStJWQfRgwLeg34eLigBsT2Rzg76UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.