I've got a branch where I've almost gotten LDAP syncing fully working, but invites don't seem to be working properly.
Even if I try to send an invite directly through the web interface, it just hangs. The user shows in the list, however the logs never show a success or failure response for the request. I've checked the SMTP settings and they appear to be correct. I'll keep debugging though.
https://git.cloudron.io/iamthefij/bitwardenrs-app/tree/ldap-sync
@jdaviescoates Mailpile has both those features: https://www.mailpile.is/
Might be a good app request.
Way back when this first came up in 2017, there was a discussion on the issue boards for Ubuntu. This is the response from the PM at Canonical who added the feature including an explanation of how it has been used in the past and how they intend to use it.
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1701068/comments/11
It can be disabled entirely by running sudo sed -i 's/^ENABLED=.*/ENABLED=0/' /etc/default/motd-news (source).
Debian support would be great, but I thought I'd present a bit more information for folks stumbling on this to read up on and make a decision on how they want to manage their server.
LDAP syncing is now available for bitwarden_rs. Check it out on the wiki.
Do you have your app shared on git.cloudron.io yet? If so I can help contribute.
@JOduMonT First off, that site is just reviewing app permissions. It’s docking Signal for requesting things like access to camera (used for taking and sending photos). That’s not really relevant here.
From a security standpoint, the Signal protocol is the gold standard for secure messaging. Other apps , like WhatsApp have even implemented it themselves.
Signal is also a non-profit and spends a considerable amount of effort in reducing knowledge needed to operate on the server. Their goal is to get to a point you don’t have to trust the server at all.
I have never heard of the app you’re recommending, but I don’t see any information about how they manage their encryption. Their website link (from Google Play) lands on some obscure website that doesn’t really load unless I turn off my tracker blockers. The site then doesn’t really indicate why I should trust them. No information on their funding or security. Also, the Play Store listing says it includes Ads. Which is a huge no-no for privacy.
Telegram is a popular app, but Signal is often recommended for security/privacy. First off, Telegram offers both encrypted and unencrypted messaging and defaults to unencrypted. Group messages cannot even be encrypted at all. In Signal, all is encrypted. Furthermore, when using encryption, Telegram uses a custom crypto algorithm they wrote rather than industry trusted ones like Signal does. This goes against a common maxim in the security industry “don’t roll your own crypto”. It could be just as secure, but less eyes on it means we just don’t know enough about it. Most professionals prefer a tried and true system.
Anyway, I’m pretty passionate about secure messaging, so I’ve done a bit of research here. All that said, unless they are willing to switch, the best one is the one your friends are using. Messaging is useless if you’re the only one with it. Kinda relates to the article will posted about encrypted email in the first place.
Got it working! Turns out I needed to enable SMTP_EXPLICIT_TLS.
Now I just have to schedule the sync task and do some cleanup. Should have a fully ready app soon.
@will just a note, I don't believe fbartels version supports a using a dump for backing up the database. This means that if the backup is taken while the db is in a transaction, it could be corrupted.
Bitwarden_rs now supports an admin API for making sqlite backups, but does not have any cron embedded. Similar to the way the LDAP sync tool works, an additional script could be added to periodically make dumps of the sqlite database so that it can be properly backed up.
Instead, the version I have is using MySQL, which leverages the native Cloudron backup and restore functionality.
That and the LDAP invite service are the real differences between the two forks. If you do not wish to use automated LDAP invites on my fork, you can select to opt out when installing. This is covered in the readme.
@girish using something like Restic for backups instead would offer encrypted block based backups. It's great for things like this where you would have lots of potentially duplicate backup data.
I know I suggested this on another thread, but using an existing backup engine would allow you to offload the complexities of efficient backups, integrity checks, and restoration as well as add support for loads more backup destinations (like B2).
I'm working on packaging Authelia as a Cloudron app, which is slightly different.
Use case is that I have a second server with some services that I would like to authenticate against my Cloudron LDAP.
@nebulon Why do you say that? Is there something wrong with SQLite? Or you just worried about when support is eventually added?
Any insights on the issues accessing the API from a scheduled task? It would be good to get this resolved anyway.
@will just a note, I don't believe fbartels version supports a using a dump for backing up the database. This means that if the backup is taken while the db is in a transaction, it could be corrupted.
Bitwarden_rs now supports an admin API for making sqlite backups, but does not have any cron embedded. Similar to the way the LDAP sync tool works, an additional script could be added to periodically make dumps of the sqlite database so that it can be properly backed up.
Instead, the version I have is using MySQL, which leverages the native Cloudron backup and restore functionality.
That and the LDAP invite service are the real differences between the two forks. If you do not wish to use automated LDAP invites on my fork, you can select to opt out when installing. This is covered in the readme.
@will Strange. It looks like you're getting some validation issue from bionic-* for some reason. Possibly the clocks are off. Maybe try again? That's not specific to this project.
It looks like you could reproduce with an new Dockerfile below, or just rebuild the existing one as caching should be in place now.
FROM cloudron/base:1.0.0@sha256:147a648a068a2e746644746bbfb42eb7a50d682437cead3c67c933c546357617
RUN apt-get update
Does it work now? If not, check your system clock and timezone.
@will the Readme should contain the details you need. It also includes an explanation on how the LDAP integration functions (as @girish said, it's not like most apps due to the client side encryption model used in Bitwarden).
If you're familiar with building a Cloudron app, you should be able to build as normal. The compiling of the binary is handled within the Dockerfile itself by leveraging multi-stage bulds.
@will Yes, you can use LDAP if you use the version I published.
https://git.cloudron.io/iamthefij/bitwardenrs-app
Updated to the latest version. I haven't updated to the latest versions of Bitwarden just yet though. I'll give that a go now.
Edit: It looks like Bitwarden_rs was updated to use a newer base image for building it's binaries. That means that when the binary used in the MySQL image is built, it's compiled against a newer version of libmariadb. It doesn't look like the Cloudron base image has been updated in a year, so I'm unable to just bump the version in the single-stage Dockerfile in my repo. However, I also have a multi-stage Dockerfile that will compile Bitwarden_rs from source against whatever version of libmariadb that is present. This should work but takes more time to build so I'm letting that run right now. I'll update when it's done. Edit: It's done!
Related, but kind off topic: Can we get an update to the Cloudron base? How will those be handled in an ongoing basis since apps are pinned (as they should be) to a particular base? I imagine there have been security updates in the last year.
Where does this stand on becoming "official" in some way? I'm still running Bitwarden off Cloudron myself as my Cloudron instance is hosting the version I'm using for development.
@JOduMonT said in Pandora: Secure your Cloudron:
I understand it is not specially related to pandora but before going further with this I would like to understand how much you are open to open your box to contributors ?
I've contributed to box before. As with many open source projects, narrowly scoped changes can be submitted and discussed on a review but if a large change is going to be submitted, it's probably best to discuss somewhere (forum, chat, RFC issue) before you invest a bunch of time.
@murgero I’m not sure what you mean. Anyone with shell access to the server as any user could do this.
@girish thanks for the quick update! L
Thinking on it a bit more, for more defense in depth I’m realizing that if the server is running as yellowtent the directory ought to be read only for that user. Otherwise a remote execution vulnerability is enough to own the server and escalate privileges.
I’m not a proper security auditor though...
Have you considered getting a professional audit?
This is not necessarily a Cloudron privilege escalation, but that Cloudron provides an attack vector for system privilege escalation.
The process I laid out will allow one to get system root access.
It puts a Cloudron server one arbitrary code execution bug away from a fully pwned system. Even an admin running a non-privileged script will allow someone to gain access to the entire server.
This will be very easy to mitigate. I believe the easiest way is rather than using/tmp, which is world writable, put the files in a directory that is owned by the cloudron user. Users can write to it by doing echo '{"blah": "blah"}' | sudo -u cloudron tee /var/cloudron/ghost.json, then have Cloudron delete the file afterwards.
Disallowing impersonation of an Admin would be one way to mitigate the escalation.
Also, managing impersonation in app would do away with this as well.