Differences between revisions 76 and 77
Revision 76 as of 2014-04-15 08:16:22
Size: 32489
Editor: Mempo
Comment: typo
Revision 77 as of 2015-01-21 01:27:01
Size: 32506
Editor: Mempo
Deletions are marked like this. Additions are marked like this.
Line 125: Line 125:

Mempo Project - Hardened Privacy


"⌘ Mempo project aims to provide most secure and yet comfortable out-of-the-box Desktop and Server computer, for professionals, business, journalists, and every-day users avoiding PRISM-like spying. ⌘"

Mempo is a software project and open team of developers working with Debian and other communities and entities for above mentioned goal.


Current status: Mempo does work right now, as extension that secures Debian (in area of kernel and gnupg). Much more things will be released in near future. To use mempo now install Debian Wheezy and then install our kernel package. See: #done. And remember to join us on IRC.

Please write down all checksums of downloaded things that you will run (or build and then run etc) that come from us, on paper. Then you can always check history, if code was trusted.

Mempo system structure

Mempo system structure

{i} Learn more about it on Mempo webpage.

See below for Download and Install instructions.

Install Mempo

This is work in progress, but it's usable right now :)

  • If you are more advanced user-developer then try all steps.
  • If you just want to use the results of our work then apply only "green" points (only β=beta and R=Released are ready to use by everyone)


  • icon/ver8.png kernel/grsecurity install SameKernel#grsecurity - but you must do setfattr in next point (even if it's not released yet)!

  • icon/ver7.png kernel/grsecurity/paxflags install grsecurity/setfattr - needed if you used our kernel /!\

  • icon/ver2.png kernel/grsecurity/rbac - in future we will provide RBAC profiles allowing to turn RBAC on by default and protect most important applications at least.

  • icon/ver4.png distro/repo: - in near future we will publish a debian-repository with created .deb files, starting with kernel. It should be available over http, as well as over Freenet and I2P.

  • icon/ver4.png priv/net/ - in near future provide one-click install for I2P, Freenet

  • In future installation will be made very easy for everyone.


Now Mempo exists as source code in various repositories. Later we will release ready .deb (signed and verifiable) and finally own .deb-repository, or in Debian repositories.

By low-security we mean that code is not so thoroughly reviewed yet, or it's developed/uploaded from not super-secured computers, but we do develop only on Linux/FOSS, encryption is always used etc - but still we know it's less than perfect.

So this is same as "normal/high" security by common standards :)

Integration with Debian

Mempo team will:

  • Upgrade existing software from upstream

  • Publish mempo-deb software, e.g. own version of Mempo/mempo-deb/tar and recommend Mempo users to upgrade immediately if they need given feature (build custom *.deb and install it) and ask them to help get them to Debian experimental

  • Upstream will be given patches and we will help to merge them

  • Debian experimental will be helped to package new software when upstream accepts it. In case of rejection or delay by upstream (if they not care about privacy&security to the same level as Mempo) to provide it as Debian custom patches

  • Debian stable - we hope most of Mempo work could, in time, reach Debian Stable to improve standard Debian security too.

Install with Debian:

  • If you are dedicated to security then install Debian Stable, and then add Mempo software on top (as of 2014-01 most software is experimental, contact as quickly for help and guidance)

  • If you are a regular Debian user who wants to improve security a bit, then use Debian Stable and try some of our packages. Try to help get them to upstream, to Experimental, to Testing, to Backports etc.

Done work

Current work

As of 2014-02:


As of 2014-01 it is intended for Mempo to:

  • Support and work inside of Debian project
  • In addition release distribution (remix/selection of packages) that includes:
  • - New software that is not yet accepted into Debian
  • - Versions newer then in Debian
  • - Release often

Mempo aims to be always Open FOSS, and put security as primary matter (e.g. at expense of usability or performance).

Project is in planning and prototyping stage, be patient :)

Found a bug or problem? Why not help us by getting involved:

Get Involved

Micro tasks:

  • {*} Please idle on our IRC channel #mempo and discuss topics that come along

  • {*} Help us with current projects e.g. SameKernel by reviewing and refactoring our code

  • {*} Just report on IRC and ask what to do, stating your skills. Be ready to wait up to 24 hours for a reply and free to ask again each few hours

  • Please try to edit our pages on Debian Wiki: our extra guidelines: short, precise, with detailed information (create paragraphs and subpages if looks too long). Links should never change! Consult us on #mempo before editing mission, general statements etc.
  • {*} Please check for bugs: ?SameKernel/#bugs and try to figure them out







Wheezy 64bit, 10 GB HDD, root

1. Build our SameKernel by following instructions there. 2. Contact us with the *.deb files created there and sha1sum of them. 3. If build instructions where not clear tell us.



Wheezy, user

1) Build our Mempo/mempo-deb by following instructions there. 2) Tell us if it worked ; Extra: 3) If on amd64, check the checksums of files are they as expected 4) With root you can install the .deb with dpkg -i foo.deb and use the created programs and test if they work fully (review sources first, or use it on test computer)


The project is a huge amount of work. If you want our work to progress faster, you can do any of the following:

  • get involved and fix some things

  • donate money to sponsor work of our developers

  • spread the word so other people would join the effort for secure and private happy future

Security topics

  • insecure-download we consider to be any download of code that will be executed in any possibly permissible or important way (sources, libraries, binary executable, scripts - but usually not images, music, etc) if that code is not strongly verified with cryptography.

  • * PGP downloads are medium secure
  • * Checksummed downloads (+PGP best) are most secure
  • * (assuming trusted source of fingerprints/checksums)

Keys (gnupg, pgp)

First you have to get our signature from keyserver by using:

gpg --keyserver pgp.mit.edu --recv-key 45953F23

To get our source code, download it from git and then verify the tag using:

LANG=C git tag -v `git describe --tags`

It should be signed (for now at least) by the same key as is published on our github account on github.com/mempo/ [[https://github.com/mempo/deterministic-kernel/blob/master/README.md|in README][, that is the key:

21A5 9D31 7421 F02E C3C3 81F3 4623 E8F7 4595 3F23

how ever this wiki page here (unless you are viewing hard-copy of it from trusted source) might have been edited too... So best to verify from multiply sources (as always).


Privacy is strongly protected by software that is included in Mempo. You can also contact us to discuss development or report bugs in a secure and privacy-respecting way. For anonymous talk try tor (with OFTC) or i2p (irc2p) in the Contact section.

If you would donate, then such resources would be given to our developers mostly, also partially to hardware, other expenses (servers,domains) people who will help us, and other FOSS projects (debian, grsecurity and other places we take software from).

  • the addresses are written on github under user mempo whom you can trust. (will pgp-sign too in future).


Contact with us: variety of ways, for secure and privacy respecting communication.




There will be variants, as planned in https://github.com/mempo/deterministic-kernel/blob/master/doc/mempo-variant.txt - versions of Mempo that very in security level (e.g. versions of kernel).

Variant desk

(previously was named as variant good)

Good protection. For Desktop. All grsecurity is used, except kmem/IOports.

Therefore video cards should work (on open-source drivers, binary blobs might not work).

/!\ binary gfx drivers will mostly not run (and would ruin security anyway)

Variant serv

Previously was called variant goodsrv.

Extra protection. For Server (or compatible desktop). All grsecurity is used, including kmem/IOports.

Therefore video cards only with best drivers will work (might require new/patched Xorg to not use IOports) - recommended for Intel gfx (as of 2013-11 probably requires patching Xorg). /!\ most gfx drivers might not work (in graphical mode) until patched /!\ binary gfx drivers are basically guaranteed to not run (and would ruin security anyway)


  • Convince GCC upstream to enable security hardening flags by default
  • - or write wrapper script and set gcc_secure and alike compilers to be used for building sensitive/all packages?
    • see dpkg-buildflags, but that is useless for binaries built by users, the compiler should do hardening by default
  • - anyone has any such flags that could be added to the Mempo/mempo-deb package gnupg application and/or libpoco library? If yes then please form the git repo and try it and notify us here+irc.

  • - Same question for kernel flags, is it secure on this front by default? Does grsecurity turn on all the needed flags, in addition to enabling some static check plugins?


Various ideas by other people, we should look into this all:

14:35 < spender> setfattr -n user.pax.flags -v "m" /usr/sbin/grub-probe
14:36 < spender> or just setfattr -x user.pax.flags /usr/sbin/grub-probe

13:57 <+minipli> dv-: ...and to not forget updating the flags on grub2 updates, you can try installing http://r00tworld.net/~minipli/grsec/pax-mark-v0.0.1.deb
13:57 <+minipli> it's a little hacky, but does the trick
13:57 < rfree_> dv-: I overall do https://raw.githubusercontent.com/mempo/deterministic-kernel/master/apps/grsec-setpax/postinstall/fs_attr_grsecurity_standard_debian.sh
13:58 < coredumb> spender: thanks for your help!
13:58 < rfree_> minipli: oh cool, is that a package that installs hooks so it re-applies setfattr after other packages are updated too? 
13:59 <+minipli> rfree_: yeah, it uses the dpkg hook from apt
14:00 <+minipli> but instead of setfattr, it uses paxctl
14:00 <+minipli> but one can easily change that, it's simple shell script
14:00 < rfree_> cool minipli, let me steal your code
14:00 < spender> HMM
14:01 <+minipli> it's not optimal, though
14:01 <+minipli> it just runs after the dpkg run, e.g., after all packages have been installed/updated

Arach recommends to consider using 0install.

Arach recommends to use LXDE as very lightweight DE.

17:02 <Arach> Only as a base. 0install or alike FTW.
17:03 <Arach> Openwall is just a saner base, but that's not what I think is the most important or time-consuming.
17:04 <Arach> Because in the end you actually *could* write some sane and reusable RBAC for a *base* system for pretty much any distro out there.
17:05 <Arach> As long as you provide applications using decentralized package managers without the deps hell the other problems, which distro you'll choose for the base wouldn't 
              really matter.
17:05 <Arach> *and the other
17:06 <Arach> To use or not to use DEs is another question, and we indeed wasted tons of time on it.

Arach and others recommend to isolate X programs with Xnested like solutions, or Waylend;

15:36 <Arach> VNC into a separate X11 session might be a better idea, as in better sort of shit.
15:36 <Arach> But still better.
15:37 <Arach> Xorg is capable of running unprivileged sessions with VNC driver.
15:38 <Arach> Maybe not out of the box (didn't check that for ages), but still may be a (poor man's) way to go.
15:38 <rfree_> so what would be best option? wayland?
15:38 <Arach> The point is: you run X11, unprivileged, without access to actual input devices, and, unlike in case of Xephyr, with all the extensions available, such as XKB.
15:39 <Arach> And use some sort of hardened VNC client to connect to it.
15:39 <Arach> But that won't work for resource-critical stuff like video, flash, etc.
15:39 <Arach> Above usable state.
15:39 <Arach> Wayland seems like the next best thing, yes.
15:40 <Arach> But not without support from some other tools.
15:40 <Arach> I didn't investigate those topics.
15:45 <Arach> http://www.mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/

Arach rised concnern that virtualization (kvm, qemu) can actually lower security.

15:30 <Arach> And btw, heavy virtualization DECREASES security.
15:30 <Arach> Both of host and guest systems.
15:30 <rfree_> oh? how?
15:31 <rfree_> there were some bugs in vm engines... afair grsec would protect from them?  and when there are no bugs, it's good isolation
15:31 <Arach> Because it introduces vulnerabilities in hypervisor which exploitation could lead to otherwise non-existent privilege escalation in guest or even to guest-to-host 
              privilege escalation.
15:32 <rfree_> even in kvm, instead xen?
15:32 <Arach> And that's a fucking truism for YEARS.
15:32 <Arach> Especially KVM and Xen.
15:32 <rfree_> so what would you use for additional isolation? 
15:34 <Arach> Separate users, SECCOMP (both modes, v1 preferably, but that's just an utopian dream in 99.99% of cases), RBAC, graphical server-level isolation (like in qubes or like 
              it's made possible in Wayland, or with some sort of X11 proxy like Xnest or Xephyr, but written in security in mind, with some seamless integration features).
15:34 <Arach> *with security
15:34 <rfree_> I read that paper about holes in kvm, right. Wasnt the conclusion that they are fixed now;  and, would not pax/rbac/grsec protect this use case?
15:35 <Arach> I suggest you asking spender and/or pipacs, what they think about security through virtualization.


SystemD is controversial choice for new init system on Debian 8(?).

Many claim it has various downsides, including security implications of running too much of tools on privileged position as PID1.

16:36 <Arach> There is consensus between credible security people: systemd is shit.
16:37 <Arach> Fucktons of shit in pid 1? Srsly.
16:37 <Arach> The only counter-argument here is "b-b-but the features!.."
16:37 <Arach> Which is pretty much speaking for itself.
16:38 <rfree> ok so the main argument is lack of isolation to separate processes (homefully with lower privilages, e.g. other uid, dropping CAP, and also option to easier contain it 
              with rbac)?
16:38 <Arach> Everything Poettering did is shit and has terrible security record, yet people don't give a shit for security, so here we are "from the Pride Rock to the pit of shame" 
16:39 <Arach> Isolation != security.
16:39 <Arach> Isolate shit, let it be pwned and let your pid 1 receive commands from it. Yeah, problem solved.
16:40 <Arach> I fucking despise that "main argument" idiocy.
16:40 <Arach> Devil is in the details, damn it.
16:40 <rfree> yeah
16:41 <rfree> but what you just written "let it be pwned and let your pid 1 receive commands from it. Yeah, problem solved."  seems to a bit defat your own argument that there should 
              be more separated things instead all in pid 1
16:41 <rfree> I guess you mean that this must be done still, but that this is not enough
16:41 <Arach> The closes to the truth overview is: it's easier to write something from scratch than to fix systemd's security.
16:41 <rfree> I was not implying that isolation is enough. So, yeap
16:42 <Arach> Separation doesn't imply verifiable authenticity.
16:43 <rfree> yea
16:43 <Arach> I could suggest architectural changes, but they are not transparent, they would require visible changes in systemd and its philosophy (if there's such a thing, formally 
              or not).
16:43 <Arach> And the author(s) obviously doesn't care that much about security.
16:43 <rfree> so which system instead of systemd?  the cgroup idea is a positive change, anything does that too?
16:43 <Arach> So good luck "cooperating" with him.
16:44 <Arach> A fucking runit could do the job, with more or less init.d-alike tricks to resolve deps, etc.
16:44 <Arach> OpenRC has some support for cgroups. Though I don't care.
16:46 <Arach> And OpenRC doen't persist as some sort of daemons. It just uses the cgroup's event handler invocation capabilities provided by the kernel.
16:46 <Arach> I'm not saying that's to any extent a superior approach, but there is such a thing.
16:50 <rfree> I suppose this is one example http://www.exploit-db.com/exploits
16:52 <Arach> Well, probably. At least OpenRC doesn't persist with tons of shitty privileged code ready to process untrusted input.

(these are quick copies from private chat, therefore non-official tone)


dbus is accused by some security researchers as being potential source of security issues, in current state.

The implementation seems to not mind security too much.

It was told that grsecurity plans to allow some ACL/control over DBus communications in future

16:53 <Arach> Speaking of dbus, you should be aware that this thing is much more serious problem than any vuln in systemd.
16:53 <rfree> is there a replacement?
16:54 <Arach> Yes. "Throw it out and forget this nightmare. Write some basic stuff from scratch, with security in mind. Take OCaml of Ada for the task, not to be a part of the same 
              ages-old fucking problem."
16:55 <rfree> so it's messaging system between varioud daemons (and apps)
16:55 <Arach> I'd avoid any IPC that was designed without security constraints in mind, that is supposed to be used by mutually trusted applications.
16:56 <Arach> Yes, a messaging system. So what?
16:56 <rfree> so replacmenet should...  1) have no implementation mistakes (low level vulns leading to say arbitrary code execution)   2) have strong authentication/authorization and 
              encryption of the communication   3) provide proper ACL (mostly result of 2) to not leak data or take dbus commands from malicious programs ?
16:56 <Arach> Don't you feel suspicious to such things by default?
16:56 <Arach> Where's your security mindset?
16:56 <Arach> Our conversations is so fucking sad, you have no idea...
16:57 <rfree> well I have no idea indeed why you bitch so much all the time :&
16:57 <rfree> you present a problem, so we look at solution
16:57 <Arach> The question is: should there be a replacement at all?
16:57 <rfree> I assume if we just rip out all communication between processes, some of this stuff actually is usefull for non-bullshit reasons
16:58 <Arach> Should there be a "universal", bloated, single-point-of-failure-or-breach protocol and a bunch of daemons?
16:58 <rfree> so limited reasonable IPC or "dbus" would be nice. you know users would like to ... I guess this is what dbus is used for... do things like be notified about usb disk 
              they inserted, eject cd, and so on
16:58 <rfree> * yes, this all things should be limited too on mempo
16:58 <Arach> Aren't unix domain socket files enough? What happened with minimalistic protocols designed to perform some single task in the most simple way?
16:59 <rfree> (e.g. white list devices)
16:59 <Arach> There's some good news about dbus, however.
16:59 <rfree> if a well-written dbus thing would exist, it could be better then each of 10 apps writting manual communication with 10 other apps, resulting in 100 comm channels
16:59 <rfree> because reducing code both meaning work for developers, and possible bugs, places to check
17:00 <rfree> either way. Ok we'll look into dbus too.

17:00 <Arach> It's currently being moved to the kernel. It's lowest layer. And spender is going to introduce dbus restricting capabilities to RBAC.

17:00 <rfree> btw I assume what we write here can be published, if you would need it hidden tell me; if you want credit/link then tell me too
17:01 <Arach> Other than that, it's still an the IPC used by modern DEs without any significant and consistent notion of trust between parties.
17:01 <Arach> And that's not even dbus' fault.

(these are quick copies from private chat, therefore non-official tone)





With debian, though if they say NO like with grsecurity we will continue work.


With Tails, they could use our kernel?

We can include Tails in easy VM.


With Openwall Linux: they could use our kernel?

We could include Openwall Linux in VM for dedicated server.

More ideas

See #ideas2.



We would like to say thank you to people who somehow helped this project to get resources. Coins, cash, hardware, domains, servers, services rented for us/our friends etc.

  • tigusoft.pl http://tigusoft.pl thank you for continuous full support!

  • da2ce7 thank you!
  • rfree continuous support.
  • this can be you - #donate

  • people giving tips e.g. on reddit


Discussion etc

sl1nk, blueeyemissing, tgs3, psi, Eleriseth, oo, octocpp, add yourself

Testing, bug reporting and small fixes

Bigger fixes and code, other tools, etc


  • rfree
  • vyrly

External Developers

  • Lunar^ thanks for dpkg reproducible branch!
  • Spender, Pipacs, #grsecurity thanks for ?GrSecurity!

  • Toad_, operhiem1 and others thanks for Freenet

  • zzz and others thanks for I2P

  • and every other developer for the other FOSS that we're using in this project!


If you should be in credits, then please contact us on IRC and paste that data you want to have listed (nick/name, contact, url, etc).

The same about Sponsors (e.g. sign message with your bitcoin/coin privkey).

Ideas 2

Even more ideas and drafts

sl1nk various ideas (evil maid, IP, MitM)

#mempo @ irc.freenode.org

<sl1nk> Meanwhile download Debian, i looked your "Threats to security and
anonymity" (https://rawgithub.com/mempo/*). I saw that you don't have a
solution for Identity Spoofing, Man-in-the-middle attack, Evil Maid attack,
phishing, DNS poisoning.
<sl1nk> That makes three categories of attacks, network, web and password
<sl1nk> There are two ways to stop the “evil maid” attack: keeping your boot
partition on a flash drive you carry at all times, or using a checksum value of
the boot sector and boot partition to detect it and change you passphrase.
<sl1nk> The only totally secure defense is to copy /boot onto a flash drive,
install GRUB on that drive, and debug this until you can boot from the flash
drive with the encrypted disk as the root filesytem.
<sl1nk> IP spoofing is a technique where a host sends out packets which claim
to be from another host. Since packet filtering makes decisions based on this
source address, IP spoofing is uses to fool packet filters. It is also used to
hide the identity of attackers using SYN attacks, Teardrop, Ping of Death and
<sl1nk> The best way to protect from IP spoofing is called Source Address
Verification, and it is done by the routing code, and not firewalling at all.
<sl1nk> turning on Source Address Verification at every boot is the right
solution for you
<sl1nk> To do that, insert the following lines somewhere in your init scripts,
before any network interfaces are initialized http://pastecode.ru/8312/
<iRelay> Title: Pastecode Без названия (at pastecode.ru)
<sl1nk> If you cannot do this, you can manually insert rules to protect every
<sl1nk> MitM-Attack, uses a technique called ARP spoofing, so you need to
filtre/block it.
<sl1nk> With HTTPS or VPN for example.
<sl1nk> For Phishing and DNS poisoning is other way... ;.;

Recent Questions

Recent questions - asked on IRC or other chats are often placed here.

Users: If you asked a question, please check in 3 days, likely a reply will be here if you missed it on the chat (or just ask us again).

Testers, devels: link users to this page using link https://wiki.debian.org/Mempo/#ql (like questions latest) or #q.


How to use VPN and Tor

The VPN-Tor model:

<rfree> hi hilby
<rfree> hilby, a friend did such configuration, it worked
<rfree> hilby, you just get and run an VPN network as usual, to have all network going via a VPN on your computer. Then, you turn on the tor server/client on this computer :)
<rfree> and that's all.
<rfree> there are things to watch over for:
<rfree> 1) would be cool to get the VPN anonymously. In general, using bitcoin to buy it, how ever bitcoin is usually not really anonymous... how ever, anyway you are still on tor anyway so you should be not easily discovered as the VPN user
<rfree> 2) timing attack. Wait some time (hours, days, weeks?) before following this instruction or someone reading this convo could exepct that the next tor from vpn user is the same guy as hilby here (if that is a problem for you)
<rfree> 3) cover traffic helps a lot. I don't remember if you can be a tor relay while on VPN, perhaps on some... if you could then it would help. If not, at least have some random tor requests in background like start bunch of tor using applications otherwise your main activity will stand out too much
<rfree> there is also  #tor over at irc.oftc.net where more people should have tips on this subject

Another option would be the Tor-VPN model. But removes your privacy in that way that if you access few things X0..X9 using this, then there will be full correlation, all 10 servers (and the ISP and for example rogue government or other adversaries spying on their traffic from backbone) will correlate and profile you. If on any site you would take action connecting you to real life then you are busted. Though it can be good in that way that the end sites see you just as a "VPN user" not as "Tor user" which some sites ban.

Advantage over just VPN, is that if adversary bribes, subpoenas or otherwise gets VPN operator data/logs, he does not have your IP.

How ever you would also need to make perfectly anonymous payment from bitcoin not connected to you in any way, sent from Tor to bitcoin (or other crypto currency) network, and register etc from Tor to remain protected.

Yet another option is VPN-Tor-VPN. This sounds like secure option, but research is needed.

Possible read:

More questions?

Questions latest: Leave us a question on IRC (irc.oftc.net best) and then check here in few days. Scroll up to see the questions.