Joey, > Could somebody explain the security implication for me? > > being able to write arbitrary strings into valid records without > overwriting any other data in utmp/wtmp can hardly be classified > as a security vulnerability.
It depends on what trust you place in the correctness of utmp/wtmp. Knowing that records are often left behind (not cleaned up or closed), you may have grown to regard them as useless data. However in that case they should be abandoned: getting rid of many setuid/setgid objects, improving security. (Records left behind may be regarded as a security issue: how do you know when all users are off and it is "safe" to reboot?) Some people would like to rely on utmp/wtmp correctness. If I see user X doing something funny: do I run to office A or office B? Some academics (foolishly?) like to allocate "participation marks" (attendance records) to students in their tutorial: based on utmp/wtmp, that is surely useless. When allowing users access to USB sticks on their "thin client" terminals, how do I know if they "own" (are logged in to) that particular terminal: run xhost and check return status, wasting resources... As I commented elsewhere, I do not think any Debian utilities ever use utmp/wtmp. Are you then at freedom to abandon them? Viewed another way: users are not meant to be able to write fake utmp/wtmp records. But they can. Anything that users can do, without authority, is a security issue. Any unexpected behaviour is a potential security issue. > (Apart from that, I'm only slightly annoyed as I had to learn about > this via MITRE / GNOME Bugzilla instead of a mail from the maintainer > to the security team?) Would I have been allowed to contact the security team directly? Are not all security-tagged bug reports monitored, as a matter of course? (Are they knowledgeable to advise on your questions above?) Cheers, Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]