155 reputation
6
bio website
location
age
visits member for 1 year, 9 months
seen Jul 19 at 5:05

Jan
7
comment How a provider can tap an internet line even for SSL encrypted connection
@Kiwy, funny about CA is that we pay them (sometimes a lot) for trust, but they are not merit any of our trust at all. (It's business oriented, not privacy oriented). If CA would share their private keys with secret agency we would never detect it (that's how it implemented in our browsers, unlike for example ssh). And they don't even need to share it, since agency need just to have their cert in the browser root CA repository, and then can just re-sign any faked certificate fully decrypt session traffic. That problem is not even attempted to be solved.
Jan
7
comment How a provider can tap an internet line even for SSL encrypted connection
@JohnDeters thanks. But your reference doesn't support your initial claim. Let's be factual. It doesn't say govt will install monitoring software on all cell phones, computers, and other gadgets brought to Olympics. This is not just ridiculously crazy, but even impossible task to do. Just think about it. So please remove that crazy statement from your answer. About Sorm, by no means I want to defend it, but this is not even comparable to Prysm (illegal secret system, that can do active attack), Sorm is non-secret (public and legal), and passive only.
Jan
1
comment Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …)
@humanityANDpeace: Additional paper from TOMOYO author sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf about the role of "pathname based access control" in security. And this sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf with more discussions on it.
Dec
31
answered Mandatory Access Control Rulesets, how to deal with Python, Bash and other interpreters?
Dec
27
awarded  Teacher
Dec
25
revised Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …)
Smack using file xattrs too, exactly like selinux.
Dec
25
awarded  Supporter
Dec
25
answered Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …)
Dec
25
suggested suggested edit on Security tradeoffs of pathname-based MAC (e.g., TOMOYO, grsecurity, AppArmor, …)
Dec
23
comment How to forbid one directory only in TOMOYO (2.5)?
I need to restrict <kernel> do you understand that? I can not just add /\*{\*}\* and exclude /home/backup/\*{\*}\*, I should only add all dirs, excluding /home/\*{\*}\*, than in /home I should explicitly add every dirs of users, except /home/backup/\*{\*}\*. That is tons of rules already. And then every time I add user I should add rule for him. All that fun because TOMOYO is lacking exclusion rules.
Dec
22
comment How to forbid one directory only in TOMOYO (2.5)?
Problem is how to forbid other processes (besides backup) write access to backup data. All processes should have full access anywhere except /home/backup/\*{\*}\*. There is no problem allowing access to backup data for backup script, since in TOMOYO you granting accesss (and only granting).
Dec
18
awarded  Tumbleweed
Dec
12
answered What is preventing the widespread common use of MAC-type systems?
Dec
11
asked How to forbid one directory only in TOMOYO (2.5)?
Nov
9
comment Possible implementations of networked+encrypted filesystem
@ tylerl @Æsahættr From the hint in ecryptfs FAQ and this ticket - ecryptfs will not work properly in networked scenario (over NFS for example) as requested in my question. Alas.
Nov
9
comment Possible implementations of networked+encrypted filesystem
@tylerl Thanks for the follow up about eCryptfs! That is interesting.
Nov
6
awarded  Editor
Nov
6
awarded  Scholar
Nov
6
comment Possible implementations of networked+encrypted filesystem
I only fear that fuse stuff is slow and encfs is not enough crypto audited. But I may be wrong.
Nov
6
revised Possible implementations of networked+encrypted filesystem
added 4 characters in body