Category Archives: security

Exploring the sudoers file: "sudo: sorry, you are not allowed to preserve the environment"

Leave a reply

On my NAS I’ve received sudo: sorry, you are not allowed to preserve the environment today when running sudo -E to transfer the environment from whatever the current shell allows sudo to see, into the new shell.

That’s because I was copying something from a remote machine to my NAS, and I (temporarily) wanted to tell remote rsync to use sudo rsync on my NAS to be sure files will be replicated correctly. While this is an absolutely horrible idea to do permanently, a temporary workaround in a safe environment is that sudo rsync should not require a root password:

ivucica ALL=NOPASSWD:/usr/bin/rsync

However, compare this to some of the defaults in /etc/sudoers:

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Without reading the sudoers(5) manpage, I decided to add ALL at the end:

ivucica ALL=NOPASSWD:/usr/bin/rsync ALL

This seemed to work, but despite a lack of a syntax error, it’s wrong (see below): now no password is required for rsync nor for any other command.

# Wrong order:
#ivucica ALL=NOPASSWD: /usr/bin/rsync, PASSWD: ALL
# Correct order:
ivucica ALL=PASSWD: ALL, NOPASSWD: /usr/bin/rsync

The best option, however, is to remove the entry completely given that allowing rsync root without a password is dangerous; even if someone managed to hijack my own account’s non-password NAS credentials, without the password itself they can’t do much.

However, looking online for this error, I realized I’ve never looked into the syntax of the sudoers file. What’s Defaults env_reset, for instance? Turns out sudoers(5) is an interesting read. If you’re seriously going to play with editing /etc/sudoers beyond just adding a user (even just specifying the NOPASSWD tag), please read the manpage and carefully experiment. Cover all the edge cases you can think of. Have someone else review your changes.

Here’s some interesting stuff:

  • #include (and presumably #includedir) directive to include a file can contain %h (a hostname) in file path
  • to match all users except root, instead of ALL we can specify ALL,!root
  • you can do things like disable setting utmp (set_utmp) or prohibit the capability to disable env_reset (setenv) — which is what I did
  • the first-time “lecture” status (‘has this user seen the sudo lecture?’) is in /var/lib/sudo/lectured and configurable using lecture_status_dir
  • the password prompt can be overridden with passprompt and can include %H FQDN, %h hostname, %p the user whose password is requested, %U the user whom we’re switching to [caveat: PAM module’s output must match Password: or username's Password:
  • there are ways to specify directives per running host (important for standardized configs deployed across an org), per requesting user, per run-as user, per command
  • there are tags to tweak execution of a command

While I haven’t actually tried all of the following, here are some “notes-to-self” on what individual fields mean. Please prefer learning the details from the manpage.

What does ALL before = mean? Those are the hosts. For instance, we can let roger run anything on all the fileservers:

Host_Alias FILESERVERS = fs1, fs, fs3
Host_Alias INTERNAL_NETWORK = 192.168.55.0/255.255.255.0
Host_Alias FINANCE = 192.168.75.128/25, 192.168.75.15

roger FILESERVERS = ALL

(Just like Host_Alias, there’s User_Alias, Runas_Alias and Cmnd_Alias.)

What’s (ALL:ALL) after =? That’s called a Runas_Spec and it’s saying “You can pretend to be any user of any group.” Let’s only allow roger to run only /usr/bin/rsync and only to do it as mainweb:

User_Alias     FINANCE_DEPLOY      = james, mike
roger          FILESERVERS         = (mainweb) /usr/bin/rsync
richard        richard-workstation = (www-data) ALL
FINANCE_DEPLOY FINANCE             = (financeweb : financeservices) /usr/bin/rsync

And what’s the ALL after (ALL:ALL)? As demonstrated, that’s the command specification.

Alright, so what’s NOPASSWD:? That’s a Tag_Spec. Each command may be prefixed with zero or more tags associated with it, such as EXEC, NOEXEC, PASSWD, NOPASSWD, MAIL, NOMAIL. For instance:

# Allow ls and cat without password, but require a password for vi.
richard richard-workstation = (www-data) NOPASSWD: /usr/bin/ls, /usr/bin/cat, NOEXEC: PASSWD: /usr/bin/vi
richard richard-workstation = (www-data) NOPASSWD: /usr/bin/ls, /usr/bin/cat, PASSWD: /usr/bin/vi

Allowlisting only some commands results in the following when a non-allowed command is run:

Sorry, user richard is not allowed to execute '/bin/bash' as root on my.machine.hostname.

And attempting to run a command from within vi when NOEXEC is specified results in:

Cannot execute shell /bin/bash

There’s even a way to set things like timeouts. But, again, read the manpage for details.

As usual, this is not advice; these are personal notes from trying to resolve an immediate issue. As this is a security-sensitive feature, for even one person that reads this and configures an important system incorrectly, please note: these notes are written as a hobby. Just like you would with PAM, NSS, LDAP, Kerberos and other things, please carefully read more authoritative documentation sources; I’m not responsible for breakage you may cause with my non-advice.

Why I choose not to use WhatsApp, Viber et al

Leave a reply

There are many messenger apps these days that have very similar features, and are widely used. I’d usually describe them as “modern” messengers. I choose not to use them. I sometimes get into discussions about why. I’ll update this post if I get new perspectives or if I find better ways to clarify my opinions.

Here are some anti-features from my perspective, widely (but not universally shared), that make me strongly prefer not using these messengers:

  • Uploading all contacts. Many modern messengers use your phone’s addressbook as the primary source for the contact list. This is, in principle, laudable. One source of contacts is a good idea1.

    However, to enable the distinction between contacts that do not use this messenger and those that do, the clients have opted to query their servers for this piece of information. To do so, they upload all your contacts, and see whether the phone number is connected to the service or not.

    Despite not having a signal of whether a contact is ‘weak’ or ‘strong’ (occasional and mainly formal interactions vs daily friendly interactions), messengers can use this to form social graphs. I don’t have a reason to believe they are doing this or exploiting this information, however, I’d prefer a smaller number of companies to have access to my contact list. I’m sure my contacts would prefer that as well.

    For this reason, I’ve chosen that the primary company that’ll have access to this is the one that already syncs my contacts and sees all my email: Google. This means I get restricted to Hangouts (which is mid-way between ‘classical’ and ‘modern’ messengers) or Allo (which is slick, but underused, and has other flaws from this list).

    • Workaround: Messengers, please let me choose not to upload all contacts. Please don’t tell me I cannot block iOS and Android from you grabbing all my contacts. Please let me share only some contacts with you, or manually enter the phone number I want to reach out to.
  • Phone numbers only, please. I use many devices. Counting off the top of my head, I use 82 ‘smart’ devices regularly and 43 sporadically. This is not counting all the operating systems I have on them: both my desktop and my old laptop have 3. How about browsers? Anything with OS X has at least Safari and Chrome.

    I change environments multiple times a day. I’ve changed countries. I could change my phone number. It’s not unreasonable that I expect my conversation to continue from one environment to the other. If I’m on my desktop, I strongly prefer not to have to take out my phone just to see that Jack has said “hi” without any other followup. And doing this while I’m dealing with a page or writing or updating a very convoluted test is very distracting. It could be an important message — should I really have to decide between 15s to get the phone and see the “hi”, making me distracted for the next 5-10min, or leaving a possibly important message unseen?

    Tying a messenger to one phone number and thus one device is ridiculous.

    • Non-workaround: Browser-based solutions. I could receive and send messages from my desktop — hurray? While I do want a web-based client to be available when I’m on a Chromebook, due to e2e they’re usually convoluted and require messages to go through your phone, only to go back through the provider’s servers (presumably re-encrypted) and to be presented in a web UI. I object to this convoluted solution on moral grounds. 🙂

      I also don’t expect I get to integrate with my desktop environment that well.

    • Non-workaround: Wearable devices. While I can see the messages quickly, I have to actually own one. My Moto 360 broke down long time ago, and I’m still waiting for a decent, affordable Android Wear 2.0 device to become available in Ireland. (If I need to get a new one, why not get a proper upgrade?)

    • Counter-example: iMessage. Yep, in place of a workaround, I’m giving a specific “modern messenger” solution. I can not only tie multiple phone numbers, but also multiple email addresses, all on multiple devices, to the same account. Messages.app (formerly iChat), an OS X feature which integrates with iMessage, is a desktop, non-browser solution that neatly integrates with the OS as well.

      I would use this messenger much more if iMessage was available on non-Apple devices and on the web.

  • Ubiquitous e2e. In principle, I like encryption. It does come with huge costs. Most messengers that implement it (well) become terrible with syncing message archives, and become terrible storing them for prolonged periods of time.

    They also have to decide where to store the keys. To keep the whole contraption secure, they often choose a storage mechanism that makes it hard to exfiltrate the keys. This is a good thing — except it prevents sync from working, and it makes it hard to introduce new devices (or browsers!) into the mix. And as I said, I use many, many devices.

    Situations where I actually, genuinely care about e2e enough to break message sync, message archiving, and make provisioning new devices for the same account difficult or impossible — those situations are very rare. I can think of maybe 5-10 cases over the past 3 years, and I can’t even recall the specifics. Cases where I wanted to find details of an old conversation, or where I wanted to continue an old discussion, those are far more frequent.

    • Counter-example: iMessage as a service is doing somewhat well here again. I am just guessing, but it seems like, once provisioned, a message will be encrypted for a particular device’s key in addition to all other devices. If a device is under-used, the key gets phased out. Messages get synced while a device is provisioned.

      Where it’s not doing so well is in-browser support. Apple recently introduced Business Chat and iCloud syncing for messages. It seems to let third-party providers create integrations with iMessage, including web based. It’s for businesses only, from what I can tell!

    • Counter-example: What about, say, WhatsApp’s web UI? Link to your phone, and have all messages go through it; a secure solution, but which I object to morally. I was going to say “I have no idea how message sync interacts with e2e with WhatsApp”, but for me it would be a non-problem with WhatsApp, as either I’d use web UI (which would presumably fetch messages from the phone), or I would not have message sync (as only one phone has a particular phone number). Possibly the key and messages get backed up to Google Drive on Android, but that solves the problem of “I’m changing the phone”, not “I’m using multiple phone numbers and non-phone devices concurrently”.

    • Workaround: What I’d really like to see happen is optional e2e. At the very least, let users agree not to e2e, and reap the benefits of message sync, nice and slick web UI, easier provisioning of new devices. When I use XMPP, I don’t bother at all turning on OTR, OMEMO, or OpenGPG (mechanisms supported in Conversations, top of the line messenger for Android) — but I strongly care about support for Message Carbons (“deliver messages to all online clients”) and Message Archive Management (“archive messages on the server and let clients request the archive”). I own my domain, so I get the benefit of not being tied to a single provider. Friends who use my secondary domain are also welcome to request archive export should they choose to spin up their own server — I’ll gladly spend the time providing them this data. (I’ll also delete the data from their archives on my server, as well, but otherwise I’d expect that I can keep my own records of these chats.)

I could also simply not worry about these problems.

For example, my personal social graph is not going to be important or even a useful source of information to sell me things4. That said, I don’t know what all the contacts in my addressbook are up to. Do I want everyone to tie me to them? It probably does not matter, but I choose to draw the line there.

I could also choose to use the messengers only on one device, and ignore notifications that come while I am focused. I could choose to accept e2e and all the downsides it brings to the sync table. I could choose to use iMessage with my Apple-toting buddies (hint: there aren’t many!). I could choose to install Facebook Messenger, tolerate battery drain, and tolerate having an additional company have access to my communications.

All that said… I don’t get that many benefits from any of these messengers. I can easily reach people I care with XMPP, Hangouts or even SMS. If SMS fails, I can, occasionally, even reactivate the Facebook account and reach out to people using Facebook Messenger on the desktop. I don’t have a good reason to compromise, or to figure out a workaround such as setting up an XMPP transport for WhatsApp. People who happen to be using WhatsApp — I can reach them through SMS as well, and often through Hangouts as well.

  1. Android allowed the apps to do it the other way around, too; applications should integrate with the Contacts app. In practice, social network apps, even if they integrated with Android’s contacts, chose to remove the integration many years ago. This is disappointing. ↩
  2. Phones: Nexus 6P (personal), iPhone 7 (work). Tablets: iPad Air (personal). Computers: desktop, Macbook Pro 2016, Digital Ocean VPS (personal), workstation, HP Chromebook (work). Other: Nvidia Shield Android TV, Samsung 6400 TV, QNAP TS-509 NAS w/ debian (personal). ↩
  3. Phones: Nexus 5, Jolla (personal). Tablets: original iPad w/ iOS 5.1.1 (personal), Nexus 7 (work). Computers: Macbook unibody late 2009, Chromebook (personal). ↩
  4. I mean, I rarely buy exactly the same product just because a friend has it. ↩

Thoughts on password managers

Leave a reply

I’ve only started looking at password managers, as recently a password that I reused as a low-importance password finally got sufficiently compromised that I have to give up on it. Yes — I finally have to seriously look at password management.

I have not actually tried out most of these. I have some experience with iCloud Keychain and Chrome’s password manager and sync. These are my notes based solely on reading about the tools. Think of them as a thought-dump; something that will help me decide over the next few days what to go with.

Context

I’m a user of:

  • many locations (home + work + travel)
  • many platforms (GNU/Linux, OS X, Windows, Android, iOS, plus an assortment of atypical OSes, including SailfishOS, ChromeOS)
  • many browsers (Chrome, Safari for battery saving, Firefox as a speedy alternative)
  • many devices and device sizes (24″ desktop touchscreen at home, smartphone, tablet)
  • many games with their own account systems

I require or strongly desire:

  • password autogeneration
  • safe bug-free synchronization
  • browser integration
    • …which stays inside its browser profile
    • external app, especially closed source, is a no-go for work use!
  • optional self-hosting
  • client side crypto
    • …unlocked with long password…
    • …and later unlocked with a PIN
  • offline access
  • easily enter passwords into games
  • mobile viewing of passwords (so I can manually type it into a terminal, for example)
  • two-factor auth for setting up sync
  • ability to back out, and switch to another solution

Being open source and free is a strong bonus, but I’m okay with using a proprietary and/or paid solution.

Examined password managers

This is not a review. I have not actually run most of the managers.

1Password

After I commented about my quest for a password manager on Twitter, two out of two people that reached back to me have surprisingly suggested this solution which seems strongly tied to Apple platforms. True, they do Windows and Android too — but, as evidenced by the order of icons on product’s website, Mac and iOS come first.

I would have always felt greatly uneasy about this (which is a strong reason why I never fully adopted iCloud Keychain), but today it’s a total no-starter.

That is, I am not going to bother even starting to try out this manager if it focuses on Apple platforms.

I am worried about the part that states that sync happens through iCloud or Dropbox (or Wi-Fi Sync). More specificially, I’m worried about what the promo page for iOS product does not state. What happens if I change password database from two devices at the same time? iCloud Core Data on Apple platforms supports merging during sync; Dropbox has datastore API. I hope these are used; I would expect them to be. Ditto for proper crypto. But the description of how to use 1Password.html to view password does not make me confident; it looks like it’s using files. It could still be doing the right thing, but… shrug

Still, if I cannot be sure I’ll be able to access my data on GNU/Linux or some of the more “obscure” platforms that I use, this is sadly a non-starter. It’s a shame, it looks like a nice product that I’d advise readers to check out.

iCloud Keychain

It’s simple, really: it’s entirely tied to Apple platforms, and to the best of my knowledge, I cannot view passwords on any other platform, much less integrate with browsers on other platforms. (Apparently it is possible to view passwords on iOS devices… but seriously, digging through Settings app?) At least Chrome uses Keychain Access on OS X, which is nice.

I’m also not too happy with the idea of having passwords in iCloud. There have been a couple of security incidents related to Apple which may or may not have happened due to users misusing the service. The ‘may not’ part is what worries me; occasionally Apple’s customer service was social-engineered, other times there were allegations of actual breaches of Apple ID authentication.

I do like the idea of syncing not just passwords, but credit card information as well, and neatly inserting it where required. If I were an Apple-only user, this would be a sufficient solution.

Google Chrome’s password sync

Chrome has its own password store which can be synced. I use this already and am mostly happy with it.

However, it’s unusable on any other browser, password generator is experimental and doesn’t seem to be manually triggerable, and accessing passwords for use in other applications is horribly hard. If I could easily get the passwords generated manually, and if I could easily find passwords (while still locking the password store after a timeout), I’d be a very happy person.

Also, given my experience with Chrome’s Bookmark Sync, where deleted bookmarks show up later, duplicated bookmarks show up later, sometimes folders are duplicated or are created as empty folders, etc, I’m highly unlikely to rely on this.

This also does not pass the self-hosted test, and partially passes the open-source test, even though I do highly trust my current employer.

LastPass

LastPass is neat. It’s a free+paid service, without a self-hosting option. But it’s neat.

It covers all major platforms that I use, and doesn’t feel like favoring any of them (there’s even a WinRT/Metro/Windows Modern application!). It has multifactor authentication. It seems to be doing its own sync protocol (so probably doesn’t lose data when merging). Its browser integration seems very powerful. There’s a command line version which is even open source. (Yes, I almost began this section of the overview by claiming this is a proprietary offering, which is true.)

They seem not to be able to see your passwords, even if the passwords are synced to their servers. CLI tool’s open source nature lets me check that — this pleases me. I also checked how the passwords are synced. Apparently, there’s an upload queue (presumably containing unsynced passwords), and the whole database seems to be optionally and as required fetched as a single blob (yes, literally blob; see also init_all(), used sometime during startup). This also pleases me — this is almost the way I would have implemented this.

I’m strongly, strongly leaning towards using this, and using its paid tier. Especially given the strong recommendations from colleagues.

(I am mildly amused that the sync server is apparently written in PHP. I am also slightly unamused by the lack of comments in lastpass-cli source code. )

KeePass ecosystem

This is a strong ecosystem built around KeePass’s file format, and one that strongly supports self-hosting. KeePass2Android seems to support SFTP. The ecosystem seems to value open source, as well: see KeePassX.

Strong contender, due to its opensource values. And UI of KeePass2Android seems nice. But I can’t get around the fact that its idea of syncing is — use a single file.

Surely we can do better than that to handle conflicts in 2015? I’d rather expose my files to a third party than lose passwords to file version conflicts.

But if I was not so afraid of losing data, this would seem like the tool to use.

zx2c4 pass (PasswordStore)

After I already posted the first iteration of this post, I got a suggestion to take a look at [pass][26]. And this one is interesting — I got it running in minutes!

Pro:

  • A simple command line tool!
  • Stores one password per file
  • Passwords are encrypted with GPG
    • Just specify your GPG ID (e.g. email address)
    • Since I store my GPG private key, PIN-protected, on my YubiKey NEO (it also does U2F, which you should use as second-factor authentication), this is awesome
  • Changes are optionally tracked with Git
    • I dislike Git, but a VCS seems perfect for this use case
  • There’s Firefox integration and there’s an Android app which seems to use OpenKeychain (hello YubiKey!)
  • The “file format” does not seem to be so much a format as just a directory with a bunch of GPG-encrypted text files in it (and optionally a git repo backing it)

Con:

  • The only Chrome extension I ran into is “in early alpha”
    • …even worse, it says: “It is not planned to add support for managing (adding,changing,removing) passwords to passext. That’s what the pass programm is for.”
    • That statement is essentially a promise for a terrible UX
  • It seems strongly oriented towards UNIX systems… what will I do on Windows?
  • Firefox addon still uses the standalone app
  • If I lose my YubiKey, I’ll lose passwords, unless I encrypt with multiple keys.

The last one is particularly worrying.

Even though, given enough time and considering how simple the “database” “format” is, I could put together proper extensions that manage passwords using in-browser GPG and Git implementations (or at least in-browser GPG + a web service to upload files to a trusted server), I’m not sure I want to invest that time. From the looks of it, I would also lose the ability to use YubiKey; searching for yubikey gpg chrome does not reveal any useful results, so I would assume that only native GPG can do this.

Windows being an afterthought would be less of an issue if the in-browser experience didn’t (seemingly always) depend on the native executable…

Closing thoughts and wishes

All the tools I took a quick look at seem like quality products that, at worst, may have just made an odd choice or two that make them inappropriate for a oh-my-eyes-they-hurt-look-at-the-number-of-devices-and-browsers users, or that lack a certain good feature.

Game passwords

None of the password managers seem appropriate for storing game passwords. I’m saddened by lack of confirmation that it is possible, under Android, to create a Bluetooth service that advertises Bluetooth HID profile; that is, I can’t confirm that it is possible to get an Android phone to behave like a keyboard. (Some sources imply this is actually not possible. Others seem to suggest it “just” requires root.)

If this were realistically possible, it would make sense for me to suggest this to developer of my chosen password manager, or to implement it myself (assuming source code availability): make an app that pretends to be a Bluetooth HID keyboard, lets me choose a password from the list, then “types” the password into whatever game I’m playing.

Maybe this would be a reason to start using Jolla as my third phone?

Self-hosting sync

Other than that, I’d really like an optionally-self-hosted service. One that would either:

  • use a one-password-per-file approach (but still properly encrypted — this is doable, right?), or
  • provide a self-hosted service with a nice CRUD API that the apps, browser extensions and CLI programs would use in the background

The first option could live on FTP, SFTP and WebDAV. If it’s properly content-addressed and append-only, you’d at worst get an outdated file. The second of those would mean less files on the filesystem, which is always nice, but would require deploying a service of some sort. (Would Camlistore be appropriate here as a backend and password store viewer? I think so.)

I definitely don’t need a “single-blob database synced to a remote filesystem” approach. That’s scary and loss-prone. Syncing is hard even if we don’t make it harder. I’m not sure I want to use something that even tries to merge two disparate single-big-blob databases, then upload the result back. (iCloud Keychain is, I expect, smarter than this; then again, it’s not a self-hosted service.)

So, choice?

I’m still making the choice LastPass and KeePass, but I’ll probably go with LastPass. Especially given the opensourced nature of the CLI tool, and how easy it is for me to validate that they’re doing the right thing with syncing passwords (at least in the CLI tool).

And when I already finished writing this post, pass came into play. It feels better than KeePass — this is, in my world, a strong contender.