Mystery solved. Samba wants to protect smbpasswd with mode 600. User must point Samba to password path. Sample smb.conf that loaded during last lenny upgrade pointed to /etc., not /etc/samba/smbpasswd. Maybe I missed a prompt during the upgrade to fully qualify the path. Maybe there wasn't any?
On Thu, Feb 12, 2009 at 8:50 PM, Stan Katz <email@example.com> wrote:
When I first experienced "promiscuous" escalation of etc mode from 755 to 600 (at least 8 to 10 years ago) I hunted down a reference by someone that this could happen if the lpd daemon was compromised. I stopped using lpd, and rebuilt my system. That system then worked fine until it was junked.* When both of my current* systems experienced this deja vue, I was quite astounded. Why me? Anyway, I logged into my AMD64 in recovery mode, and began to exit out just about every service script in init.d I felt I could get away without. The mode changing stopped. I then painfully began reenabling scripts, and rebooting, until the mode on etc escalated. Unless this is a very clever exploit, it seems the problem is limited to samba. I haven't had a mode escalation problem, either from reboots, or just power on time since stopping samba on both machines.
Either I'm doing something to cause gross misbehavior in samba, there is a bug in samba, or, taking the path of paranoia, someone along the samba source chain might be a sabateur. I'll start with the first proposition.* My first symptom was the "i have no name" prompts in my xterms when whoami failed. There is a lot of that going on out there on the net, but no one every mentions as a possible cause, an overescalated mode on etc. I'll be ripping my samba out, and replacing it with a surgical install via dpkg from the Debian main site. We'll see....
On Thu, Feb 12, 2009 at 3:11 PM, The Well - Systems Administrator <firstname.lastname@example.org> wrote:
600 on /etc is technically more secure than the default 755 with normal POSIX systems, not less. If this is an exploit, it's one that locks things down tighter than they should normally be.
Giacomo is correct that these incorrect perms can cause other issues, though not security related ones that I can think of.
Are there a different set of perms you had set on /etc manually? Any other indication that you've been exploited, or just a hunch based on circumstantial weirdness based on unexpected /etc privs and bastille?
Boyd Stephen Smith Jr. wrote:
On Wednesday 11 February 2009 23:26:45 Stan Katz wrote:
I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb
10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen
since the lpd exploit of the 1990's. This symptom manifests itself as
either a random escalation of the etc directory mode up to 600, or a
consistent escalation to mode 600 upon reboot.
My /etc is mode 755. *Why would that be a problem? *Some user/programs may need to read data out of the directory and root (the owner of my /etc) certainly needs write permissions.
I don't remember why the lpd
exploit did this. If this is an exploit, it shakes my confidence in debian
I don't see how a 600 /etc can be exploited. *Do you have any other records that would indicate you are exploited, or is this just fear-mongering?
Also, the Bastille firewall on the
AMD64 began locking down port 80 after about 10min of operation. Adding 80
to all interfaces didn't help. Only shutting down Bastille cleared the
Sounds like a bug in Bastille. *Can you reproduce reliably? *Have you checked your configuration? *If both, has you filed a bug yet?
I fear this is another indication of the exploit.
How/Why would these be related?
Has anyone else experienced this misbehavior after an upgrade?
Not here. *I've been running Lenny for a number of months.
suggestions, other than a complete disk wipe on both machines? In any case,
where would I go for a trusted rebuild, if there truly is a sabateur in the
ranks of the Debian maintainers?
I'm forwarding to debian-security; perhaps they will have suggestions. *This topic is more appropriate for that list than debian-user anyway.