← Back to team overview

sslug-teknik team mailing list archive

Fejl i passwd systemet

 

Jeg skrev dette til sikkerhed for et par dage siden, men det er li'som
ikke kommet noget ud af det..


Jeg fatter ikke en disse.
For kort tid siden flyttede jeg en RH6.2 til ny disk på samme måde jeg
plejer uden problemer.

Alting virkede indtil for få dage siden, hvor jeg opdagede at alm.
brugere kunne logge ind uden passwd, hvilket jeg umiddelbart tilskrev
brugen af grpunconv/pwunconv og tilbage igen med grpconv/pwconv efter
flytningen til ny disk. Nyt passwd, no problemas.

Da jeg fik den ide at undersøge /etc/passwd og group, opdagede jeg flg.:

På en række indbyggede system konti, hvor man jo slet ikke skal kunne
logge ind, kunne logges ind uden passwd. Flg. konti opførte sig sådan:

  bin, daemon, sys, adm, lp, mail, news, uucp, games, gopher, ftp,
  nobody, gdm, postgres, pvm, operator

I /etc/shadow så et typisk entry sådan ud:
  bin::11561:0:99999:7:::
      ^
Skulle have været :*:

For disse konti manglede desuden root i /etc/gshadow, f.eks.:
 
bin:::bin,daemon                                                           
 
daemon:::bin,daemon                                                        

Skulle have været:
 
bin:::root,bin,daemon                                                           
 
daemon:::root,bin,daemon                                                        


Efter jeg havde fixet ovenstående, virkede det hele, bortset fra at jeg
ikke kunne starte xfs.

I group, gshadow, passwd og shadow filerne var 'xfs' omdøbt til 'fs', så
jeg havde s'fø'li' rettet det til 'xfs', da jeg fixede de andre fejl.
Da jeg ændrede det tilbage til 'fs' virkede kunne jeg starte xfs .

'xfs' har da ikke ændret sig til 'fs' mellem kerne 2.2.14 og 2.2.19 ?
På en gammel sjældent brugt pc med std. RH6.2, står der 'xfs' i filerne.


Noget at sige til jeg er lidt uforstående?
Maskinen er næsten fuldt opdateret, kører 2.2.19, står bag min firewall,
nettet har ingen public services kørende, og tcp regler bruger "! -y"
til SYN check.

Jeg har checket systemet, og det ser ikke ud til nogen har været på
besøg.

Har nogen dårlige erfaringer med grp/pwunconv og -conv?
Andre forklaringer?
-- 
Regards,
           Mr Dev - Mogens Valentin
    http://www.mrdev.com - mrdev@xxxxxxxxx
OpenSource Security - Networking - Programming