The latest stage3 for amd64 comes with at least 2 user accounts that don't make sense to me, possibly more: operator and smmsp. I cannot explain the former, but the latter might belong to a qmail installation on a release building system. In combination with a insecure configuration on pam (ldap, unix2, no deny), it allowed a passwordless login to the system via ssh, granting shell access. Well, the misconfiguration was my fault, but. But... I suggest a re-examination of the passwd before shipping, stripping it of user accounts that aren't of any use to a fresh system, this might be part of QA of releases maybe. I work at a research facility as a network admin, and I was lucky I had more defense in place. I can imagine more people running ldap+unix2 in insecure configurations, or even other combinations that might be dangerous. Since not every distribution comes with this operator user, I hereby question its place in gentoo unless proven useful. From the incident at our facility - I can't provide logs, sorry - I can assume there's ssh scanners that are targetting a combination of password-less 'operator' users with pam_ldap+pam_unix2 (or other configurations that result in password-less access). I've specified platform amd64 since I only checked todays amd64 stage3, but I *do* assume it's a general problem with all platforms. The security team may change bug report fields as appropiate of course. Even if it turns out not to be a bug, the purpose of those extraneous users should have a plausible explanation to the public - IMHO. I don't think these accounts have been added with malicious purpose, they look like remnants from old stuff or a build system. But I don't have a slightest idea, why they're still there. Yours, satmd
They aren't remnants of the build system. They are users created by stable packages in the system set.
Well, ok, that's a possibility I included. In that case, I lack a way to trace back the origin of those users, because I have no plausibile log (from a integrity point of view) for those users. # getent passwd | grep operator operator:x:11:0:operator:/root:/bin/bash that's the only hint I have about this user's existance. Most packages at least have a gecos of "created by portage". So, if this isn't a bug with the user existance per se, wouldn't it be a good idea to document system users that are required (or "useradd"ed) by packages in the system depencencies? My idea of a stage 2/3 is to expect the stage tar to be self-contained, trying its best to have a state that can be explained as much as possible. Not leaving grey bits. Most people won't even notice the existance, nor question it, I guess - which makes it hard to explain the importance. I think it's a matter of trust. I'd expect to have a place to check what a stage untar should look like, and I'd expect to contain the aspect of 'getent passwd'. I agree this isn't actually much of a security issue, but a documentation issue of sorts maybe. But it *can* become a security issue with misconfiguration, in which case it'll become hard to tackle down the ultimate origin of the problem. With the few information regular users have they cannot even clearly decicde about wether to remove the user or not. That's an integrity issue there.
I'm sorry if my English is somewhat poor. I'd expect to have a way to understand the users that exist in a fresh gentoo system and I do not find a plausible way for those two user as there's not even a log.
smmsp has been removed already. operator is currently there by design, and someone will have to start a thread on gentoo-dev about its. your "insecure configuration" argument is useless. if your config is screwed up, that's your fault. passwd database is completely meaningless -- all entries in shadow are marked with "*" by default which means "dont allow login".
My goal is to have a system that is fully on itself plausible in a security context. I already said that my insecure configuration was the reason I only noticed that user. I don't blame gentoo for my faults. But when I was trying to find some kind of list or *any* explanation for the users in /etc/passwd, I only check the logs of my *newly* installed packages. I miss documentation about users included on itself with the tarballs. That'd be the base for any decision wether I'd want to keep or remove a certain user. I lack that base for a decision. Those 2 users are the ones I felt most prominent and had in memory when opening this bug. I'm trying to get a whole picture of my systems, and having users around I cannot explain from neither logs nor any documentation, I don't want to just accept that. Especially since I don't feel that is necessary. Documenting the pre-packaged users doesn't add security, but it does add trust in the QA process of releases. As in "we didn't just miss this". It makes the QA process more complete and it doesn't add much cost to it. To put the bug report at a novice level: Should I keep or remove that user? I would not be able to decide.
> Kristian Fiskerstrand 2014-06-22 20:49:08 UTC > Status: CONFIRMED → RESOLVED > Resolution: --- → WONTFIX 1) Why? No comment? 2) Who are you?!
Hi Jaak, This bug was discussed within the security team yesterday and the conclusion is that we do not consider this a security bug. We are currently dealing with a number of bugs in the backlog, and closing bugs that we do not expect to follow up on is part of this process.
And as for who he is, he is a security team apprentice, see https://wiki.gentoo.org/wiki/Project:Security. In this case, he does speak for a decision made by the security team.
(In reply to Kristian Fiskerstrand from comment #7) > This bug was discussed within the security team yesterday and the conclusion > is that we do not consider this a security bug. > > We are currently dealing with a number of bugs in the backlog, and closing > bugs that we do not expect to follow up on is part of this process. Ok. But I think this should still be considered a non-security bug, because user "operator" still a completely useless entry in /etc/passwd. Maybe re-open and re-assign to bug-wranglers? (In reply to Chris Reffett from comment #8) > And as for who he is, he is a security team apprentice, see > https://wiki.gentoo.org/wiki/Project:Security. In this case, he does speak > for a decision made by the security team. Ok, this explains why there was no badge image next to his name in b.g.o like gentoo devs and security team members etc do. It was just a bit confusing for me to see a seemingly random b.g.o user not related to this bug closing it without comment. :)
(In reply to Jaak Ristioja from comment #9) > Ok. But I think this should still be considered a non-security bug, because > user "operator" still a completely useless entry in /etc/passwd. Maybe > re-open and re-assign to bug-wranglers? We were thinking about that too. However, given the age of this bug we decided otherwise. As per your request, I'm reassigning this to the base-system team.
The operator user was not used by CoreOS, but existed because it exists in the Gentoo Portage system from which CoreOS is derived. The operator user exists on several UNIX-like systems and is present in many automated SSH attack scripts, so the presence of an operator user that could be accessed without a valid password left systems vulnerable to these automated attacks. This meant that the vulnerability was rapidly exploited on CoreOS systems with publicly accessible SSH services. [...] For good measure, the operator account on CoreOS systems has been further restricted, with its login shell removed to go with its already disabled password https://coreos.com/blog/security-brief-coreos-linux-alpha-remote-ssh-issue.html
I made the same change for Gentoo on Linux since this is also our default on *bsd. The commit id is e8bbd89. This will be in baselayout-2.3.
