From eugen@leitl.org Fri Sep 20 04:58:06 2013 From: Eugen Leitl To: cypherpunks@lists.cpunks.org Subject: Re: [Cryptography] A lot to learn from "Business Records FISA NSA Review" Date: Fri, 20 Sep 2013 10:58:00 +0200 Message-ID: <20130920085800.GO10405@leitl.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1306293770289422070==" --===============1306293770289422070== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Ray Dillinger ----- Date: Thu, 19 Sep 2013 10:02:35 -0700 From: Ray Dillinger To: cryptography(a)metzdowd.com Subject: Re: [Cryptography] A lot to learn from "Business Records FISA NSA Re= view" User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130828 Icedove/17.= 0.8 On 09/16/2013 07:58 AM, Perry E. Metzger wrote: > Well, we do know they created things like the (not very usable) > seLinux MAC (Multilevel Access Control) system, so clearly they do > some hacking on security infrastructure. SeLinux seems to be targeted mostly at organizational security, whereas the primary need these days is not organizational, but uniform. That is to say, we don't in practice see many situations where different levels and departments of an organization have complex and different rules for how and whether they can access each other's information and complex requirements for audit trails. What we see is simpler; we see systems used by people who have more or less uniform requirements and don't much need routine auditing, except for one or two administrators. More useful than the complexity of SeLinux would be a relatively simple system in which ordinary Unix file permissions were cryptographically enforced. If for example read permissions on a file are exclusive to some user or some group, then that file should be encrypted so that no one else, even if the bytes are accessible to them by some means, should be able to make sense of it, and the configuration options should include not storing the key to it anywhere in the system -- let the user plug a USB stick in to give the key for his session, and let the user remove it to take that key away again whenever he's not using it, rather than leave it around on the hard drive somewhere potentially to be accessed by someone else at some other time. We have spent years learning to protect the operating system from damage by casual mistakes and even from most actual attacks, because for years control of the computer itself was the only notable asset that needed to be protected. It is still true that control of the computer is always at least as valuable as everything else that it could be used to compromise, but with unencrypted files it can compromise far too much. And the value of what is stored in individual accounts has gotten far too high to *NOT* give protecting them at least as much thought as protecting root's access rights. Photographs, banking records, schedules, archived mail going back for years, browser histories, "wallets" that contain many other keys, etc, etc. This is far different from old days when what was on a user's account was basically a few programs the user used and some text or code that the user had written. We need to catch up. Bear _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- --=20 Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 --===============1306293770289422070== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xMiAoR05V L0xpbnV4KQoKaVFJY0JBRUJBZ0FHQlFKU1BBNFlBQW9KRVBSdU5JbXNpVTdGUzk0UC8yL1o2S3Vh TzdrL21qbm5rMDQvWWs3YwpCbUk2T0Exb3MvWWRuQkNCY3FrTk9kWjR5R1BjOExKdHRMUzdCcmtj WWt1cTlxUVQ4ZjRCSmpGYWdoZG9mWXBwCkZwVjIyUVIrUUNKVGJNL25ESkZpaUVUM3NEbFFNYmtP d2QxVzVTNGxqRXYza0x5eVhYUVR1Rmx3UHgxQkZURk0KNWNsUHVIREFKeHhuU3hEUTlhTW1HT2ov cHQ5U3NGNzNIM3pyN0hUb0dMalREUHRycHBrQ3Z6dzJIQi9wS2tBbwpTeFJrOG5rOHVEWkV4VDhl WEQ1NlJWRkdxeTYxR2tPdkJiY2MxZ0dqempCdnBNN203dldLNzJvMk1HSUdNTzhnCk40ZW94YXFh RGNCUndReEJhMUZ4ZnpnWnFTWXlmdjBBUUw2Z2l1b0tMcXpacE5SeksvS2ZzamE1S1psVjYyYVgK SlZIRUFFZG15NDJucGFkcEsyajZ4dUViMlVwREY4RmIvM0N6MlRZSkpIeldFVzdGTmdxbjZrR0ZX NzJGQkYrTwpaZ29nclV0V1ZRVlhQd0wxL2lSRGMrYVdLdmw5aDhZMnlxNjNTTDh0MzdiemJuS2VG bnA4SW44dDM5MFFmb3JBCi9RTUFyL0hXZmRiWHJEZjlMdnc5Mi9YSWwrMU9sTlpYKzQyTnUzM1N2 bUNiNStIclJzQmtUN3o0N016VE5TK0cKd1hKL3pZdjBYQnExdWRRSS9XUlRWbkF1NTJyVUxMRHVI M25oc09FTDZWZityYjhmN25SNUhyVHZmV29MaFhkMgovYjJ6eWtkTVhrTlduc3dsOUg3WCsxWEpE UmVvQ2Q1T0RrSFkzLzhmU290OXI0MUlDMC9MYWxWenpmUGNTWXEzCjlab3RtSk84WVlZR2RhOTE5 ai9TCj1xeVJ0Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============1306293770289422070==--