Mempo Project - Hardened Privacy


The project is temporarily on hold, while we prepare move to newer version of grsecurity.

Due to legal and/or business reasons, grsecurity project will remain fully open in the testing branch, not in the stable branch. And anyway stable branch was getting too old for Debian Jessie.

Expect us back by 2015.12.01.



"⌘ 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 :)



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:

Install with Debian:

Done work

Current work

As of 2014-02:


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

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:







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:

Security topics

Keys (gnupg, pgp)

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

gpg --keyserver --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 [[|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).


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




There will be variants, as planned in - 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)



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
13:57 <+minipli> it's a little hacky, but does the trick
13:57 < rfree_> dv-: I overall do
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>

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
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.


Discussion etc

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

Testing, bug reporting and small fixes

Bigger fixes and code, other tools, etc


External Developers


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 @

<sl1nk> Meanwhile download Debian, i looked your "Threats to security and
anonymity" (*). 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
<iRelay> Title: Pastecode Без названия (at
<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 (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 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 ( best) and then check here in few days. Scroll up to see the questions.