<title>Solene'%</title>
<description></description>
<link>gemini://perso.pw/blog/</link>
<atom:link href="gemini://perso.pw/blog/rss.xml" rel="self" type="application/rss+xml" />
<item>
<![CDATA[
This blog post is an introduction to the smartphone and security oriented operating system GrapheneOS.
=> GrapheneOS official project web page
Thanks to my patrons support, last week I have been able to replace my 6.5 years old BQ Aquaris X which has been successfully running Lineage OS all that time, by a Google Pixel 8a now running GrapheneOS.
Introducing GrapheneOS is a daunting task, I will do my best to present you the basics information you need to understand if it might be useful for you, and let a link to the project FAQ which contains a lot of valuable technical explanations I do not want to repeat here.
GrapheneOS (written GOS from now on) is an Android based operating system that focuses security. It is only compatible with Google Pixel devices for multiple reasons: availability of hardware security components, long term support (series 8 and 9 are supported at least 7 years after release) and the hardware has a good quality / price ratio.
The goal of GOS is to provide users a lot more control about what their smartphone is doing. A main profile is used by default (the owner profile), but users are encouraged to do all their activities in a separate profile (or multiples profiles). This may remind you about Qubes OS workflow, although it does not translate entirely here. Profiles can not communicate between each others, encryption is done per profile, and some permissions can be assigned per profile (installing apps, running applications in background when a profile is not used, using the SIM...). This is really effective for privacy or security reasons (or both), you can have a different VPN per profile if you want, or use a different Google Play login, different applications sets, whatever! The best feature here in my opinion is the ability to completely stop a profile so you are sure it does not run anything in the background once you exit it.
When you make a new profile, it is important to understand it is like booting your phone again, the first log-in with the profile you will be asked questions like if you started the system for the first time. All settings have the defaults values, and any change is limited to the profile only, this includes ringtones, sound, default apps, themes… Switching between profile is a bit painful, you need to get the top to bottom dropdown menu at full size, then tap the bottom right corner icon and choose the profile you want to switch to, and tap the PIN of that profile. Only the owner profile can toggle important settings like 4G/5G network, or do SIM operations and other "lower level" settings.
GOS has a focus on privacy, but let the user in charge. Google Play and Google Play Services can be installed in one click from a dedicated GOS app store which is limited to GOS apps only, as you are supposed to install apps from Google Play, F-droid or Accrescent. Applications can be installed in a single profile, but can also be installed in the owner profile which lets you copy it to other profiles. This is actually how I do, I install all apps in the user profile, I always uncheck the "network permission" so they just can't do anything, and then I copy them to profiles where I will use it for real. There is no good or bad approach, this fits your need in terms of usability, privacy and security.
Just to make sure it is clear, it is possible to use GOS totally Google free, but if you want to use Google services, it is made super easy to do so. Google Play could be used in a dedicated profile if you ever need it once.
The installation was really simple as it can be done from the web page (from a Linux, Windows or macOS system), by just clicking buttons in the correct order from the installation page. The image integrity check can be done AFTER installation, thanks to the TPM features in the phone which guarantees the boot of valid software only, which will allow you to generate a proof of boot that is basically a post-install checksum. (More explanations in GOS website). The whole process took approximately 15 minutes between plugging the phone to my computer and using the phone.
It is possible to install from the command line, I did not test it.
Updates are 100% over-the-air (OTA), which mean the system is able to download updates over network. This is rather practical as you never need to do any adb command to push a new image, which have always been a stressful experience for me when using smartphones. GOS automatically download base system updates and offer you to reboot to install it, while GOS apps will just be downloaded and update in place. This is a huge difference from LineageOS which always required to manually download new builds, and applications updates were parts of the big image update.
A cool thing with GOS is the tight controls offered over applications. First, this is done by profile, so if you use the same app in two profiles, you can give different permissions, and secondly, GOS allows you to define a scope to some permissions. For example, if an application requires storage permission, you can list which paths are allowed, if it requires contacts access, you can give a list of contacts entries (or empty).
GOS Google Play installation (which is not installed by default) is sand-boxed to restrict what it can do, they also succeeded at sand-boxing Android Auto. (More details in the FAQ). I have a dedicated Android Auto profile, the setup was easy thanks to the FAQ has a lot of permissions must be manually given for it to work.
GOS does not allow you to become root on your phone though, it just gives you more control through permissions and profiles.
I did not try CPU/GPU intensive tasks for now, but there should be almost no visible performance penalty when using GOS. There are many extra security features enabled which may lead to a few percent of extra CPU usage, but there are no benchmark and the few reviews of people who played high demanding video games on their phone did not notice any performance change.
GOS website has a long and well detailed list of hardening done over the stock Android code, you can read about them on the following link.
=> GrapheneOS website: Exploitation Protection
As an example, here is how I configured my device, this is not the only way to proceed, so I just share it to give the readers an idea of what it looks like for me:
After a long week of use, I came up with this. At first, I had a separate profile for TOTP, but having to switch back and forth to it a dozen time a day was creating too much friction.
I chose to buy a Google Pixel 8a 128 GB as it was the cheapest of the 8 and 9 series which have a 7 years support, but also got a huge CPU upgrade compared to the 7 series. The device could be bought at 300€ on second hand market and 400€ brand new.
The 120 Hz OLED screen is a blast! Colors are good, black is truly black (hence dark themes for OLED reduce battery usage and looks really great) and it is super smooth.
There is no SD card support, which is pretty sad especially since almost every Android smartphone support this, I guess they just want you to pay more for storage. I am fine with 128 GB though, I do not store much data on my smartphone, but being able to extend it would have been nice.
The camera is OK, I am not using it a lot and I have no comparison, from reviews I have read they were saying it is just average.
Wi-Fi 6 works really fine (latency, packet loss, range and bandwidth) although I have no way to verify its maximum bandwidth because it is faster than my gigabit wired network.
The battery lasts long, I use my smartphone a bit more now, the battery approximately drops by 20% for a day of usage. I did not test charge speed.
I am really happy with GrapheneOS, I finally feel in control of my smartphone and I never considered it a safe device before. I never really used an Android ROM from a manufacturer or iOS, I bet they can provide a better user experience, but they can not provide anything like GrapheneOS.
LineageOS was actually ok on my former BQ Aquaris X, but there were often regressions, and it did not provide anything special in terms of features, except it was still having updates for my old phone. GrapheneOS on the other hand provides a whole new experience, that may be what you are looking for.
This system is not for everyone! If you are happy with your current Android, do not bother buying a Google Pixel to try GOS.
The stock Android version supports profiles (this can be enabled in system -> users -> allow multiple users), but there is no way to restrict what profiles can do, it seems they are all administrators. I have been using this on our Android tablet at home, it is available on every Android phone as well. I am not sure if it can be used as a security feature as this.
]]>
gemini://perso.pw/blog//articles/intro-to-grapheneos.gmi
Tue, 14 Jan 2025 00:00:00 GMT
<![CDATA[
This blog post is part of a series that will be about Systemd ecosystem, today's focus is on journaling.
Systemd got a regrettable reputation since its arrival mid 2010. I think this is due to Systemd being radically different than traditional tooling, and people got lost without a chance to be noticed beforehand they would have to deal with it. The transition was maybe rushed a bit with a half-baked product, in addition to the fact users had to learn new paradigms and tooling to operate their computer.
Nowadays, Systemd is working well, and there are serious non-Systemd alternatives, so everyone should be happy. :)
Journald is the logging system that was created as part of Systemd. It handles logs created by all Systemd units. A huge difference compared to the traditional logs is that there is a single journal file acting as a database to store all the data. If you want to read logs, you need to use journalctl command to extract data from the database as it is not plain text.
Most of the time journald logs data from units by reading their standard error and output, but it is possible to send data to journald directly.
On the command line, you can use systemd-cat to run a program or pipe data to it to send them to logs.
Here is a list of the most common cases you will encounter:
journalctl -f
journalctl -n 2000
journalctl -u nginx.service
journalctl -g somepattern
journalctl --since="10 minutes ago" or journalctl --since="1 hour ago" or journalctl --since=2024-12-01
journalctl --since="today" --until="1 hour ago" or journalctl --since="2024-12-01 12:30:00" --until="2024-12-01 16:00:00"
journalctl -b
journalctl -b -1
journalctl --utc
You can use multiple parameters at the same time:
journalctl -n 200 -u nginx -b
journalctl -f -g wg-content -u nginx
If you want to bypass journald and send all messages to syslog to handle your logs with it, you can edit the file /etc/systemd/journald.conf to add the line ForwardToSyslog=Yes.
This will make journald relay all incoming messages to syslog, so you can process your logs as you want.
Restart journald service: systemctl restart systemd-journal.service
=> systemd-journald man page | journald.conf man page
Journalctl contains a lot more information than just the log line (raw content). Traditional syslog files contain the date and time, maybe the hostname, and the log message.
This is just for information, only system administrators will ever need to dig through this, it is important to know it exists in case you need it.
Here is what journald stores for each line (pretty printed from json output), using samba server as an example.
# journalctl -u smbd -o json -n 1 | jq
{
"_EXE": "/usr/libexec/samba/rpcd_winreg",
"_CMDLINE": "/usr/libexec/samba/rpcd_winreg --configfile=/etc/samba/smb.conf --worker-group=4 --worker-index=5 --debuglevel=0",
"_RUNTIME_SCOPE": "system",
"__MONOTONIC_TIMESTAMP": "749298223244",
"_SYSTEMD_SLICE": "system.slice",
"MESSAGE": " Copyright Andrew Tridgell and the Samba Team 1992-2023",
"_MACHINE_ID": "f23c6ba22f8e02aaa8a9722df464cae3",
"_SYSTEMD_INVOCATION_ID": "86f0f618c0b7dedee832aef6b28156e7",
"_BOOT_ID": "42d47e1b9a109551eaf1bc82bd242aef",
"_GID": "0",
"PRIORITY": "5",
"SYSLOG_IDENTIFIER": "rpcd_winreg",
"SYSLOG_TIMESTAMP": "Dec 19 11:00:03 ",
"SYSLOG_RAW": "<29>Dec 19 11:00:03 rpcd_winreg[4142801]: Copyright Andrew Tridgell and the Samba Team 1992-2023\n",
"_CAP_EFFECTIVE": "1ffffffffff",
"_SYSTEMD_UNIT": "smbd.service",
"_PID": "4142801",
"_HOSTNAME": "pelleteuse",
"_SYSTEMD_CGROUP": "/system.slice/smbd.service",
"_UID": "0",
"SYSLOG_PID": "4142801",
"_TRANSPORT": "syslog",
"__REALTIME_TIMESTAMP": "1734606003126791",
"__CURSOR": "s=1ab47d484c31144909c90b4b97f3061d;i=bcdb43;b=42d47e1b9a109551eaf1bc82bd242aef;m=ae75a7888c;t=6299d6ea44207;x=8d7340882cc85cab",
"_SOURCE_REALTIME_TIMESTAMP": "1734606003126496",
"SYSLOG_FACILITY": "3",
"__SEQNUM": "12376899",
"_COMM": "rpcd_winreg",
"__SEQNUM_ID": "1ab47d484c31144909c90b4b97f3061d",
"_SELINUX_CONTEXT": "unconfined\n"
}The "real" log line is the value of SYSLOG_RAW, everything else is created by journald when it receives the information.
As the logs can be extracted in JSON format, it becomes easy to parse them properly using any programming language able to deserialize JSON data, this is far more robust than piping lines to AWK / grep, although it can work "most of the time" (until it does not due to a weird input).
On the command line, you can query/filter such logs using jq which is a bit the awk of JSON. For instance, if I output all the logs of "today" to filter lines generated by the binary /usr/sbin/sshd, I can use this:
journalctl --since="today" -o json | jq -s '.[] | select(._EXE == "/usr/sbin/sshd")'
This command line will report each line of logs where "_EXE" field is exactly "/usr/sbin/sshd" and all the metadata. This kind of data can be useful when you need to filter tightly for a problem or a security incident.
The example above was made easy as it is a bit silly in its form: filtering on SSH server can be done with journalctl -u sshd.service --since=today.
Journald is a powerful logging system, journalctl provides a single entry point to extract and filter logs in a unified system.
With journald, it became easy to read logs of multiple services over a time range, and log rotation is now a problem of the past for me.
]]>
gemini://perso.pw/blog//articles/systemd-journald-cheatsheet.gmi
Wed, 25 Dec 2024 00:00:00 GMT
<
]]>
gemini://perso.pw/blog//articles/pi-hole.gmi
Sat, 21 Dec 2024 00:00:00 GMT
<![CDATA[
This blog post is about designing firewall rules, not focusing on a specific operating system.
The idea came after I made a mistake on my test network where I exposed LAN services to the Internet after setting up a VPN with a static IPv4 on it due to too simplistic firewall rules. While discussing this topic on Mastodon, some mentioned they never know where to start when writing firewall rules.
Firewall rules are evaluated one by one, and the evaluation order matters.
Some firewall use a "first match" type, where the first rule matching a packet is the rule that is applied. Other firewalls are of type "last match", where the last matching rule is the one applied.
The first step when writing firewall rules is to block all incoming and outgoing traffic.
There is no other way to correctly configure a firewall, if you plan to block all services you want to restrict and let the default allow rule do its job, you are doing it wrong.
As all flows should be blocked by default, you have to list what should go through the firewall, inbound and outbound.
In most cases, you will want to allow outbound traffic, except if you have a specific environment on which you want to only allow outgoing traffic to a certain IP / port.
For inbound traffic, if you do not host any services, there are nothing to open. Otherwise, make a list of TCP, UDP, or any other ports that should be reachable, and who should be allowed to reach it.
When writing your rules, whether they are inbound or outbound, be explicit whenever possible about this:
Eventually, in some situations you may want to filter by source and destination port at the same time. This is usually useful when you have two servers communicating over a protocol enforcing both ports.
This is actually where I failed and exposed my LAN minecraft server to the wild. After setting up a VPN with a static IPv4 address, I only had a "allow tcp/25565" rule on my firewall as I was relying on my ISP router to not forward traffic. This rule was not effective once the traffic was received from the VPN, although it would have been filtrated when using a given network interface or a source network.
If you want to restrict the access of a critical service to a some user (1 or more), but that they do not have a static IP address, you should consider using a VPN for this service and restrict the access to the VPN interface only.
Firewall rules will evolve over time, you may want to write for your future you why you added this or that rule. Ideally, use a version control system on the firewall rules file, so you can easily revert changes or track history to understand a change.
When applying the firewall rules the first time, you may have made a mistake and if it is on remote equipment with no (or complicated) physical access, it is important to prepare an escape.
There are different methods, the most simple is to run a command in a second terminal that sleeps for 30 seconds before resetting the firewall to a known state, you have to run this command just before loading the new rules. So if you are locked out after applying, just wait 30 seconds to fix the rules.
If you want to monitor your firewall, consider adding counters to rules, it will tell you how many times it was evaluated/matched and how many packets and traffic went through. With nftables on Linux they are named "counters", whereas OpenBSD packet filter names this "label".
It is also possible to log packets matching a rule, this can be useful to debug an issue on the firewall, or if you want to receive alerts in your logs when a rule is triggered.
Writing firewall rules is not a hard task once you identified all flows.
While companies have to maintain flow tables, I do not think it can be useful for a personal network (your mileage may vary).
]]>
gemini://perso.pw/blog//articles/writing-firewall-rules.gmi
Wed, 11 Dec 2024 00:00:00 GMT
<![CDATA[
Last month, I decided to leave the OpenBSD team as I have not been using OpenBSD myself for a while. A lot of people asked me why I stopped using OpenBSD, although I have been advocating it for a while. Let me share my thoughts.
First, I like OpenBSD, it has values, and it is important that it exists. It just does not fit all needs, it does not fit mine anymore.
Here is a short list of problems that, while bearable when taken individually, they summed up to a point I had to move away from OpenBSD.
As part of staying relevant on the DevOps market, I need to experiment and learn with a lot of stuff, this includes OCI containers, but also machine learning and some weird technologies. Running virtual machines on OpenBSD is really limited, running programs headless with one core and poor performance is not a good incentive to work at staying sharp.
As part of my consultancy work, I occasionally need to run proprietary crap, this is not an issue when running it in a VM, but I can not do that on OpenBSD without a huge headache and very bad performance.
I have grievances against OpenBSD file system. Every time OpenBSD crash, and it happens very often for me when using it as a desktop, it ends with file corrupted or lost files. This is just not something I can accept.
Of course, it may be some hardware compatibility issue, I never have issues on an old ThinkPad T400, but I got various lock up, freeze or kernel panic on the following machines:
Would you like to keep using an operating system that daily eat your data? I don't. Maybe I am doing something weirds, I don't know, I have never been able to pinpoint why I got so many crashes although everyone else seem to have a stable experience with OpenBSD.
I moved from OpenBSD to Qubes OS for almost everything (except playing video games) on which I run Fedora virtual machines (approximately 20 VM simultaneously in average). This provides me better security than OpenBSD could provide me as I am able to separate every context into different spaces, this is absolutely hardcore for most users, but I just can't go back to a traditional system after this.
=> Earlier blog post: Why one would use Qubes OS?
In addition, I have learned the following Linux features and became really happy of it:
When using a desktop for gaming, I found Fedora Silverblue to be a very solid system with reliable upgrades, good quality and a lot of software choice.
I got too many issues with OpenBSD, I wanted to come back to it twice this year, but I just have lost 2 days of my life due to all the crashes eating data. And when it was working fine, I was really frustrated by the performance and not being able to achieve the work I needed to do.
But as I said, I am glad people there are happy OpenBSD users who enjoy it and have a reliable system with it. From the various talks I had with users, the most common (by far) positive fact that make OpenBSD good is that users can understand what is going on. This is certainly a quality that can only be found in OpenBSD (maybe NetBSD too?).
I will continue to advocate OpenBSD for situations I think it is relevant, and I will continue to verify OpenBSD compatibility when contributing to open source software (last in date is Peergos). This is something that matters a lot for me, in case I go back to OpenBSD :-)
]]>
gemini://perso.pw/blog//articles/why-i-stopped-using-openbsd.gmi
Mon, 18 Nov 2024 00:00:00 GMT
<![CDATA[
This blog post is about Floccus, a self-hosting web browser bookmarks and tabs syncing software.
What is cool with Floccus is that it works on major web browsers (Chromium, Google Chrome, Mozilla Firefox, Opera, Brave, Vivaldi and Microsoft Edge), allowing sharing bookmarks/tabs without depending on the web browser integrated feature, but it also supports multiple backends and also allow the sync file to be encrypted.
=> Floccus official project website
The project is actively developed and maintained.
If you want to share a bookmark folder with other people (relatives, a team at work), do not forget to make a dedicated account on the backend as the credentials will be shared.
There is not much to setup, but the process looks like this:
After you are done, repeat the process on another web browser if you want to enable sync, otherwise Floccus will "only" serve as a bookmark backup solution.
It is the first bookmark sync solution I am happy with, it just works, supports end-to-end encryption, and does not force you to use the same web browser across all your devices.
Before this, I tried integrated web browser sync solutions, but self-hosting them was not always possible (or a terrible experience). I gave a try to "bookmark managers" (linkding, buku, shiori), but whether in command line or with a web UI, I did not really like it as I found it rather impractical for daily use. I just wanted to have my bookmarks stored in the browser, and be able to easily search/open them. Floccus does the job.
]]>
gemini://perso.pw/blog//articles/selfhosted-bookmark-sync.gmi
Tue, 05 Nov 2024 00:00:00 GMT
<![CDATA[
As I moved my infrastructure to a whole new architecture, I decided to only expose critical accesses to dedicated administration systems (I have just one). That workstation is dedicated to my infrastructure administration, it can only connect to my servers over a VPN and can not reach the Internet.
This blog post explains why I am doing this, and gives a high level overview of the setup. Implementation details are not fascinating as it only requires basics firewall, HTTP proxy and VPN configuration.
I wanted to have my regular computer not being able to handle any administration task, so I have a computer "like a regular person" without SSH keys, VPN and a password manager that does not mix personal credentials with administration credentials ... To prevent credentials leaks or malware risks, it makes sense to uncouple the admin role from the "everything else" role. So far, I have been using Qubes OS which helped me to do so at the software level, but I wanted to go further.
This is a rather quick and simple explanation of what you have to do in order to set up a dedicated system for administration tasks.
The admin workstation I use is an old laptop, it only needs a web browser (except if you have no internal web services), a SSH client, and being able to connect to a VPN. Almost any OS can do it, just pick the one you are the most conformable with, especially with regard to the firewall configuration.
The workstation has its own SSH key that is deployed on the servers. It also has its own VPN to the infrastructure core. And its own password manager.
Its firewall is configured to block all in and out traffic except the following:
The HTTP proxy exposed on the infrastructure has a whitelist to allow some fqdn. I actually want to use the admin workstation for some tasks, like managing my domains through my registrar web console. Keeping the list as small as possible is important, you do not want to start using this workstation for browsing the web or reading emails.
On this machine, make sure to configure the system to use the HTTP proxy for updates and installing packages. The difficulty of doing so will vary from an operating system to another. While Debian required a single file in /etc/apt/apt.conf.d/ to configure apt to use the HTTP proxy, OpenBSD needed both http_proxy and https_proxy environment variables, but some scripts needed to be patched as they do not use the variables, I had to check fw_update, pkg_add, sysupgrade and syspatch were all working.
Ideally, if you can afford it, configure a remote logging of this workstation logs to a central log server. When available, auditd monitoring important files access/changes in /etc could give precious information.
My SSH servers are only reachable through a VPN, I do not expose it publicly anymore. And I do IP filtering over the VPN, so only the VPN clients that have a use to connect over SSH will be allowed to connect.
When I have some web interfaces for services like Minio, Pi-Hole and the monitoring dashboard, all of that is restricted to the admin workstations only. Sometimes, you have the opportunity to separate the admin part by adding a HTTP filter on a /admin/ URI, or if the service uses a different port for the admin and the service (like Minio). When enabling a new service, you need to think about all the things you can restrict to the admin workstations only.
Depending on your infrastructure size and locations, you may want to use dedicated systems for SSH/VPN/HTTP proxy entry points, it is better if it is not shared with important services.
You will need to exchange data to the admin workstation (rarely the other way), I found nncp to be a good tool for that. You can imagine a lot of different setup, but I recommend picking one that:
=> Previous blog post: Secure file transfer with NNCP
I learned about this method while reading ANSSI (French cybersecurity national agency) papers. While it may sound extreme, it is a good practice I endorse. This gives a use to old second hand hardware I own, and it improves my infrastructure security while giving me peace of mind.
In addition, if you want to allow some people to work on your infrastructure (maybe you want to set up some infra for an association?), you already have the framework to restrict their scope and trace what they do.
Of course, the amount of complexity and resources you can throw at this is up to you, you could totally have a single server and lock most of its services behind a VPN and call it a day, or have multiple servers worldwide and use dedicated servers to enter their software defined network.
Last thing, make sure that you can bootstrap into your infrastructure if the only admin workstation is lost/destroyed. Most of the time, you will have a physical/console access that is enough (make sure the password manager is reachable from the outside for this case).
]]>
gemini://perso.pw/blog//articles/my-admin-workstation.gmi
Wed, 23 Oct 2024 00:00:00 GMT
<![CDATA[
In this blog post, you will learn how to make secure backups using Restic and a S3 compatible object storage.
Backups are incredibly important, you may lose important files that only existed on your computer, you may lose access to some encrypted accounts or drives, when you need backups, you need them to be reliable and secure.
There are two methods to handle backups:
Both workflows have pros and cons. The pull backups are not encrypted, and a single central server owns everything, this is rather bad from a security point of view. While push backups handle all encryption and accesses to the system where it runs, an attacker could destroy the backup using the backup tool.
I will explain how to leverage S3 features to protect your backups from an attacker.
S3 is the name of an AWS service used for Object Storage. Basically, it is a huge key-value store in which you can put data and retrieve it, there are very little metadata associated with an object. Objects are all stored in a "bucket", they have a path, and you can organize the bucket with directories and subdirectories.
Buckets can be encrypted, which is an important feature if you do not want your S3 provider to be able to access your data, however most backup tools already encrypt their repository, so it is not really useful to add encryption to the bucket. I will not explain how to use encryption in the bucket in this guide, although you can enable it if you want. Using encryption requires more secrets to store outside of the backup system if you want to restore, and it does not provide real benefits because the repository is already encrypted.
S3 was designed to be highly efficient for retrieving / storage data, but it is not a competitor to POSIX file systems. A bucket can be public or private, you can host your website in a public bucket (and it is rather common!). A bucket has permissions associated to it, you certainly do not want to allow random people to put files in your public bucket (or list the files), but you need to be able to do so.
The protocol designed around S3 was reused for what we call "S3-compatible" services on which you can directly plug any "S3-compatible" client, so you are not stuck with AWS.
This blog post exists because I wanted to share a cool S3 feature (not really S3 specific, but almost everyone implemented this feature) that goes well with backups: a bucket can be versioned. So, every change happening on a bucket can be reverted. Now, think about an attacker escalating to root privileges, they can access the backup repository and delete all the files there, then destroy the server. With a backup on a versioned S3 storage, you could revert your bucket just before the deletion happened and recover your backup. In order to prevent this, the attacker should also get access to the S3 storage credentials, which is different from the credentials required to use the bucket.
Finally, restic supports S3 as a backend, and this is what we want.
There is a list of open source and free S3-compatible storage, I played with them all, and they have different goals and purposes, they all worked well enough for me:
=> Seaweedfs GitHub project page | Garage official project page | Minio official project page
A quick note about those:
You need to pick a S3 provider, you can self-host it or use a paid service, it is up to you. I like backblaze as it is super cheap, with $6/TB/month, but I also have a local minio instance for some needs.
Create a bucket, enable the versioning on it and define the data retention, for the current scenario I think a few days is enough.
Create an application key for your restic client with the following permissions: "GetObject", "PutObject", "DeleteObject", "GetBucketLocation", "ListBucket", the names can change, but it needs to be able to put/delete/list data in the bucket (and only this bucket!). After this process done, you will get a pair of values: an identifier and a secret key
Now, you will have to provide the following environment variables to restic when it runs:
AWS_DEFAULT_REGION which contains the region of the S3 storage, this information is given when you configure the bucket.
AWS_ACCESS_KEY which contains the access key generated when you created the application key.
AWS_SECRET_ACCESS_KEY which contains the secret key generated when you created the application key.
RESTIC_REPOSITORY which will look like s3:https://$ENDPOINT/$BUCKET with $ENDPOINT being the bucket endpoint address and $BUCKET the bucket name.
RESTIC_PASSWORD which contains your backup repository passphrase to encrypt it, make sure to write it down somewhere else because you need it to recover the backup.
If you want a simple script to backup some directories, and remove old data after a retention of 5 hourly, 2 daily, 2 weekly and 2 monthly backups:
restic backup -x /home /etc /root /var restic forget --prune -H 5 -d 2 -w 2 -m 2
Do not forget to run restic init the first time, to initialize the restic repository.
I really like this backup system as it is cheap, very efficient and provides a fallback in case of a problem with the repository (mistakes happen, there is not always need for an attacker to lose data ^_^').
If you do not want to use S3 backends, you need to know Borg backup and Restic both support an "append-only" method, which prevents an attacker from doing damages or even read the backup, but I always found the use to be hard, and you need to have another system to do the prune/cleanup on a regular basis.
This approach could work on any backend supporting snapshots, like BTRFS or ZFS. If you can recover the backup repository to a previous point in time, you will be able to access to the working backup repository.
You could also do a backup of the backup repository, on the backend side, but you would waste a lot of disk space.
]]>
gemini://perso.pw/blog//articles/secure-backups-with-s3.gmi
Tue, 22 Oct 2024 00:00:00 GMT
<![CDATA[
Snap package format is interesting, while it used to have a bad reputation, I wanted to make my opinion about it. After reading its design and usage documentation, I find it quite good, and I have a good experience using some programs installed with snap.
=> Snapcraft official website (store / documentation)
Snap programs can be either packaged as "strict" or "classic"; when it is strict there is some confinement at work which can be inspected on an installed snap using snap connections $appname, while a "classic" snap has no sandboxing at all. Snap programs are completely decorrelated from the host operating system where snap is running, so you can have old or new versions of a snap packaged program without having to handle shared library versions.
The following setup explains how to install snap programs in a template to run them from AppVMs, and not how to install snap programs in AppVMs as a user, if you need this, please us the Qubes OS guide linked below.
Qubes OS documentation explains how to setup snap in a template, but with a helper to allow AppVMs to install snap programs in the user directory.
=> Qubes OS official documentation: install snap packages in AppVMs
In a previous blog post, I explained how to configure a Qubes OS template to install flatpak programs in it, and how to integrate it to the template.
=> Previous blog post: Installing flatpak programs in a Qubes OS template
All commands are meant to be run as root.
=> Snapcraft official documentation: Installing snap on Fedora
Installing snap is easy, run the following command:
dnf install snapd
To allow "classic" snaps to work, you need to run the following command:
sudo ln -s /var/lib/snapd/snap /snap
Now, you have to configure snap to use the http proxy in the template, this command can take some time because snap will time out as it tries to use the network when invoked...
snap set system proxy.http="http://127.0.0.1:8082/" snap set system proxy.https="http://127.0.0.1:8082/"
You need to prevent snap from searching for updates on its own as you will run updates when the template is updated:
snap refresh --hold
To automatically update snap programs when the template is updating (or doing any dnf operation), create the file /etc/qubes/post-install.d/05-snap-update.sh with the following content and make it executable:
#!/bin/sh
if [ "$(qubesdb-read /type)" = "TemplateVM" ]
then
snap refresh
fiTo add the menu entry of each snap program in the qube settings when you install/remove snaps, create the file /usr/local/sbin/sync-snap.sh with the following content and make it executable:
#!/bin/sh
# when a desktop file is created/removed
# - links snap .desktop in /usr/share/applications
# - remove outdated entries of programs that were removed
# - sync the menu with dom0
inotifywait -m -r \
-e create,delete,close_write \
/var/lib/snapd/desktop/applications/ |
while IFS=':' read event
do
find /var/lib/snapd/desktop/applications/ -type l -name "*.desktop" | while read line
do
ln -s "$line" /usr/share/applications/
done
find /usr/share/applications/ -xtype l -delete
/etc/qubes/post-install.d/10-qubes-core-agent-appmenus.sh
doneInstall the package inotify-tools to make the script above working, and add this to /rw/config/rc.local to run it at boot:
/usr/local/bin/sync-snap.sh &
You can run the script now with /usr/local/bin/sync-snap.sh & if you plan to install snap programs.
If you want to browse and install snap programs using a nice interface, you can install the snap store.
snap install snap-store
You can run the store with snap run snap-store or configure your template settings to add the snap store into the applications list, and run it from your Qubes OS menu.
The setup on Debian is pretty similar, you can reuse the Fedora guide except you need to replace dnf by apt.
=> Snapcraft official documentation: Installing snap on Debian
More options to install programs is always good, especially when it comes with features like quota or sandboxing. Qubes OS gives you the flexibility to use multiple templates in parallel, a new source of packages can be useful for some users.
]]>
gemini://perso.pw/blog//articles/snap-on-qubesos.gmi
Sat, 19 Oct 2024 00:00:00 GMT
<![CDATA[
nncp (node to node copy) is a software to securely exchange data between peers. Is it command line only, it is written in Go and compiles on Linux and BSD systems (although it is only packaged for FreeBSD in BSDs).
The website will do a better job than me to talk about the numerous features, but I will do my best to explain what you can do with it and how to use it.
=> nncp official project website
nncp is a suite of tools to asynchronously exchange data between peers, using zero knowledge encryption. Once peers have exchanged their public keys, they are able to encrypt data to send to this peer, this is nothing really new to be honest, but there is a twist.
What is cool with nncp is that files you receive are unpacked in a given directory and their integrity is verified. This is sometimes more practical than a network share in which you are never sure when you can move / rename / modify / delete the file that was transferred to you.
I identified a few "realistic" use cases with nncp:
This let a lot of room for other imaginative use cases.
My preferred workflow with nncp that I am currently using is a group of three syncthing servers.
Each syncthing server is running on a different computer, the location does not really matter. There is a single share between these syncthing instances.
The servers where syncthing are running have incoming and outgoing directories exposed over a NFS / SMB share, with a directory named after each peer in both directories. Deposing a file in the "outgoing" directory of a peer will make nncp to prepare the file for this peer, put it into the syncthing share and let it share, the file is consumed in the process.
In the same vein, in the incoming directory, new files are unpacked in the incoming directory of emitting peer on the receiver server running syncthing.
Why is it cool? You can just drop a file in the peer you want to send to, it disappears locally and magically appears on the remote side. If something wrong happens, due to ACK, you can verify if the file was delivered and unpacked. With three shares, you can almost have two connected at the same time.
It is a pretty good file deposit that requires no knowledge to use.
This could be implemented with pure syncthing, however you would have to:
This does not scale well.
Side note, I am using syncthing because it is fun and requires no infrastructure. But actually, a webdav filesystem, a Nextcloud drive or anything to share data over the network would work just fine.
On each peer, you have to generate a configuration file with its private keys. The default path for the configuration file is /etc/nncp.hjson but nothing prevents you from storing this file anywhere, you will have to use the parameter -cfg /path/to/config file in that case.
Generate the file like this:
nncp-cfgnew > /etc/nncp.hjson
The file contains comments, this is helpful if you want to see how the file is structured and existing options. Never share the private keys of this file!
I recommend checking the spool and log paths, and decide which user should use nncp. For instance, you can use /var/spool/nncp to store nncp data (waiting to be delivered or unpacked) and the log file, and make your user the owner of this directory.
Now, generate the public keys (they are just derived from the private keys generated earlier) to share with your peers, there is a command for this that will read the private keys and output the public keys in a format ready to put in the nncp.hjson file of recipients.
nncp-cfgmin > my-peer-name.pub
You can share the generated file with anyone, this will allow them to send you files. The peer name of your system is "self", you can rename it, it is just an identifier.
When import public keys, you just need to add the content generated by the command nncp-cfgmin of a peer in your nncp configuration file.
Just copy / paste the content in the neigh structure within the configuration file, just make sure to rename "self" by the identifier you want to give to this peer.
If you want to receive data from this peer, make sure to add an attribute line incoming: "/path/to/incoming/data" for that peer, otherwise you will not be able to unpack received file.
Now you have peers who exchanged keys, they are able to send data to each other. nncp is a collection of tools, let's see the most common and what they do:
echo "https://some-domain/uri/" | nncp-exec peername wget to trigger a remote wget.
If you use the client / server model over TCP, you will also use:
If you use asynchronous file transfers, you will use:
For sending files, just use nncp-file file-path peername:, the file name will be used when unpacked, but you can also give the filename you want to give once unpacked.
A directory could be used as a parameter instead of a file, it will be stored automatically in a .tar file for delivery.
Finally, you can send a stream of data using nncp-file stdin, but you have to give a name to the resulting file.
This was not really clear from the documentation, so here it is how to best use nncp when exchanging files using plain files, the destination is /mnt/nncp in my examples (it can be an external drive, a syncthing share, a NFS mount...):
When you want to sync, always use this scheme:
nncp-xfer -rx /mnt/nncpnncp-toss -gen-acknncp-xfer -keep -tx -mkdir /mnt/nncpnncp-rm -all -ackThis receives files using nncp-xfer -rx, the files are stored in nncp spool directory. Then, with nncp-toss -gen-ack, the files are unpacked to the "incoming" directory of each peer who sent files, and ACK are generated (older versions of nncp-toss does not handle ack, you need to generate ack befores and remove them after tx, with nncp-ack -all 4>acks and nncp-rm -all -pkt < acks).
text/xml; charset=utf-8This content has been proxied by September (3851b).