"authentication" doesn't work anymore

fakk_ · 10-27-2008, 05:34 AM

Hi guys!

Yesterday I shut down my system (Debian testing) and this very morning, just after the boot process had finished (with no error whatsoever), I ran into troubles (and I think that they're somehow "auth-related"):

1) X doesn't work anymore as a normal user (as root it still works)
When launching 'startx' it says:

Code:

X: unable to open wrapper config file /etc/X11/Xwrapper.config
X: user not authorized to run the X server, aborting.
xinit: Server error.

I've checked Xwrapper.config and it seems correct. Here's the content:

Code:

allowed_users=console
nice_value=0

I've also changed "console" to "anybody" but nothing happens.
Permissions are set to 600.

By setting permissions to 644 I've managed to move a step forward. Now the error says:

Code:

Fatal server error:
Cannot move old log file ("/var/log/Xorg.0.log" to "/var/log/Xorg.0.log"

Again I've manually renamed the file, which brought me to this error:

Code:

Fatal server error:
Cannot open log file "/var/log/Xorg.0.log"

I've dist-upgraded (so that all X-related packages are up to date), yet nothing changes.

2) su doesn't work anymore

If I login as a root directly from the login console, there are no problems.
If instead I try to su as another user, failures are experienced.
auth.log as of yesterday:

Code:

Oct 26 18:11:49 elisewin su[21566]: Successful su for root by fakk
Oct 26 18:11:49 elisewin su[21566]: + pts/1 fakk:root

auth.log as it looks today:

Code:

Oct 27 11:20:40 elisewin su[5126]: pam_unix(su:auth): authentication failure; logname=root uid=1000 euid=1000 tty=pts/2 ruser=fakk rhost=  user=root
Oct 27 11:20:42 elisewin su[5126]: pam_authenticate: Authentication failure
Oct 27 11:20:42 elisewin su[5126]: FAILED su for root by fakk
Oct 27 11:20:42 elisewin su[5126]: - pts/2 fakk:root

3) Examples of other auth-related tasks I can't perform anymore
For instance, crontab editing:

Code:

fakk@elisewin:~$ crontab -e
/var/spool/cron/crontabs/fakk: Permission denied

As far as I know, a dpkg-reconfigure libpam-runtime doesn't do anything.
Uninstalling and then reinstalling it seems to be a crazy task (apt suggests me that I'm about to do something potentially harmful).

That said, what do you think of my situations? Any advice before I screw up the whole installation (more than I've already done :P)?

Thank you in advance (and sorry for the lengthiness).

--
fakk

estabroo · 10-27-2008, 09:02 AM

It really sounds like you've removed all your setuid bits from these programs. X is normally a suid program so it runs as root and gives the user permission to access that Xwrapper.config file. Same with su its a suid program so you can elevate permissions to switch to another user.

As root you'll need to chmod u+s /bin/su; chmod ug+s /usr/bin/X

fakk_ · 10-27-2008, 09:44 AM

Hi estabroo!
First of all, thank you for your help and the time you've dedicated to me!

Quote:

Originally Posted by estabroo

It really sounds like you've removed all your setuid bits from these programs. X is normally a suid program so it runs as root and gives the user permission to access that Xwrapper.config file. Same with su its a suid program so you can elevate permissions to switch to another user.

As root you'll need to chmod u+s /bin/su; chmod ug+s /usr/bin/X

Now that you make me think of, as you've correctly pointed out, all the programs I've used should have their setuid (or setgid in some cases) set.

The really weird thing is this:

Code:

elisewin:~# find / -perm /u+s
/bin/su
/bin/ping
/bin/mount
/bin/ping6
/bin/umount
/usr/bin/X
/usr/bin/Xorg
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/lppasswd
/usr/bin/fileshareset
/usr/bin/traceroute6.iputils
/usr/bin/arping
/usr/bin/kgrantpty
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/start_kdeinit
/usr/bin/tcptraceroute.mt
/usr/bin/sudoedit
/usr/bin/traceroute-nanog.genuine
/usr/bin/kpac_dhcp_helper
/usr/lib/eject/dmcrypt-get-device
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/pt_chown
/usr/sbin/exim4
/usr/arm-linux/lib/pt_chown

Look what happens when I try to invoke 'passwd' (I swear I do know my password

):

Code:

elisewin:/home/fakk# su fakk
fakk@elisewin:~$ passwd
Changing password for fakk.
(current) UNIX password: 
passwd: Authentication failure
passwd: password unchanged
fakk@elisewin:~$ exit

Interestingly, take a peek at this ('login' command issued as root):

Code:

elisewin:/home/fakk# login
elisewin login: fakk
Password: 
Last login: Mon Oct 27 13:27:38 CET 2008 on pts/6
Linux elisewin 2.6.21.3-20070606 #1 Wed Jun 6 13:31:12 CEST 2007 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No mail.
fakk@elisewin:~$

I'm pretty confident, everything boils down to some setuid/setgid bit thing. Still I'm puzzled, as I have no idea about what to do next.

estabroo · 10-27-2008, 09:56 AM

Did you turn on some feature like selinux or apparmor and its preventing you from escalating your privs?

fakk_ · 10-27-2008, 10:04 AM

Nope, nothing like that.

Apart from launching a dist-upgrade this morning, after I noticed all these things, there's nothing else (as far as I remember).

estabroo · 10-27-2008, 10:43 AM

Anything showing up in the log files or in dmesg?

estabroo · 10-27-2008, 10:45 AM

Check the ownership of those files and make sure root still owns them.

fakk_ · 10-27-2008, 11:06 AM

Log files seem normal:
- auth.log records that normal users keep on failing when trying to become superusers;
- debug/dmesg/messages/syslog/kern.log are all clean;
- Xorg.log only reports the root sessions errors (as normal users can't move nor write it).

As for the owner of the files with their setuid bit set, it seems to be root:

Code:

elisewin:/var/log# find / -perm /u+s -exec stat -c %U\ %n {} \;
root /bin/su
root /bin/ping
root /bin/mount
root /bin/ping6
root /bin/umount
root /usr/bin/X
root /usr/bin/Xorg
root /usr/bin/chfn
root /usr/bin/chsh
root /usr/bin/sudo
root /usr/bin/lppasswd
root /usr/bin/fileshareset
root /usr/bin/traceroute6.iputils
root /usr/bin/arping
root /usr/bin/kgrantpty
root /usr/bin/newgrp
root /usr/bin/passwd
root /usr/bin/gpasswd
root /usr/bin/start_kdeinit
root /usr/bin/tcptraceroute.mt
root /usr/bin/sudoedit
root /usr/bin/traceroute-nanog.genuine
root /usr/bin/kpac_dhcp_helper
root /usr/lib/eject/dmcrypt-get-device
root /usr/lib/dbus-1.0/dbus-daemon-launch-helper
root /usr/lib/openssh/ssh-keysign
root /usr/lib/pt_chown
root /usr/sbin/exim4
root /usr/arm-linux/lib/pt_chown

Bonus info: I have a cron job running every day at 2 o'clock. The output is, normally, mailed to my user. This time, no mail arrived, although the job has been run, as showed by this entry in the syslog:

Code:

Oct 27 14:00:01 elisewin /USR/SBIN/CRON[6490]: (fakk) CMD (/usr/local/bin/updatecasts)

Should I start thinking that my system is possessed?
Frankly, I've never ever seen something like this

estabroo · 10-27-2008, 11:50 AM

Well maybe not possessed but certainly different. How about mount options, is your /, /usr, /sbin being mounted with nosuid option

try mount with no options and it should give you the mount information for everything mounted.

fakk_ · 10-27-2008, 01:44 PM

As a matter of fact, they are!

Code:

elisewin:~# mount
/dev/hda6 on / type reiserfs (rw,nosuid,noatime,notail)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/hda7 on /home type reiserfs (rw,noatime)
/dev/hda8 on /mnt/other type reiserfs (rw,noexec,nosuid,nodev)

Here's an excerpt from the 'mount' man page (might come in handy also to others running into the same trouble):

Code:

              nosuid Do  not  allow  set-user-identifier  or  set-group-identifier  bits  to take
                     effect. (This seems safe, but is in fact rather unsafe  if  you  have  suid‐
                     perl(1) installed.)

A quick'n'dirty way of checking if that was the problem:

Code:

elisewin:/# mount -o remount,rw,suid /
elisewin:/# su fakk
fakk@elisewin:/$ su
Password: 
elisewin:/#

Yikes!

Thank you, man! You've definitely made my day!

For the sake of completeness, here's my current '/etc/fstab':

Code:

# <file system> <mount point>   <type>  <options>                 <dump>  <pass>
proc            /proc           proc    defaults                    0       0
/dev/hda6       /               reiserfs defaults,nosuid,notail,noatime    0       1
/dev/hda7       /home           reiserfs noatime                    0       2
/dev/hda8       /mnt/other      reiserfs defaults,user              0       2
/dev/hda5       none            swap    sw                          0       0
/dev/hdb        /media/cdrom0   udf,iso9660 user,noauto             0       0
/dev/mp3player  /mnt/mp3player  vfat    defaults,user,noauto        0       0
/dev/sda1       /mnt/pen        vfat    defaults,user,noauto        0       0
/dev/hda1       /mnt/win        vfat    defaults,user,noauto        0       0

I really can't imagine how come the option nosuid has been set for "/"

Besides, as it strikes, even my /mnt/other has the nosuid option set, although in the /etc/fstab was specified the string "defaults,user,rw" (which should result into "rw,suid,dev,exec,auto,user,async").

Thank you again for sticking with me all this time.
Without your help I wouldn't even have imagined what could have possibly been the cause!

estabroo · 10-27-2008, 02:00 PM

Glad it turned out to be something "normal" and not a possession.