223757 2008-05-26 21:20 0000 =app-mobilephone/kmobiletools-0.5.0_beta3 adds $USER to root group with <udev-122-r1 2008-08-14 12:15:09 0000 1 1 1 Unclassified Gentoo Security Auditing unspecified All Linux RESOLVED FIXED P2 normal --- 233790 1 hwoarang@gentoo.org security@gentoo.org kde@gentoo.org mobile-phone@gentoo.org udev-bugs@gentoo.org hwoarang@gentoo.org 2008-05-26 21:20:06 0000 app-mobilephone/kmobiletools-0.5.0_beta3 is requesting root priviledges and after that it adds normal user to root group --- output (when running from terminal)-- kbuildsycoca running... Adding user XXXXXX to group root Adding user XXXXXX to group uucp Weaver::finish: done. Reproducible: Always Steps to Reproduce: 1.emerge app-mobilephone/kmobiletools-0.5.0_beta3 2.Run the wizard 3.Fill in the root password 4.Add new device Actual Results: app-mobilephone/kmobiletools-0.5.0_beta3 is requesting root priviledges and after that it adds normal user to root group I think is very very insecure what it happens. I might do something wrong and end up with my user to root group but I double checked it on two machines rbu@gentoo.org 2008-06-01 14:03:02 0000 KDE/Mobile, can you guys look into this? deathwing00@gentoo.org 2008-06-01 14:30:43 0000 I guess we'll have to talk with upstream... deathwing00@gentoo.org 2008-06-01 14:51:19 0000 I can confirm it does happen. 'RockMan' might know why this is happening. deathwing00@gentoo.org 2008-06-01 15:42:59 0000 Sorry, I looked again at it. It does NOT happen to me. deathwing00@gentoo.org 2008-06-01 15:47:36 0000 17:44 <deathwing01> do you want me to add you to the bug? 17:45 <RockMan> ok, but please post a comment: i need a precise log to see if it's a bug or not 17:46 <RockMan> because, if we have, for instance, /var/lock belonging to root:root then the normal (and wanted) application behaviour is to add the current user to that group (that's root) 17:46 <RockMan> so if you've root:root in one of that items it's a distro-configuration bug.. that's all 17:47 <deathwing01> I have to say that my user already belonged to uucp group deathwing00@gentoo.org 2008-06-01 16:26:04 0000 So, from instructions on comment #5: $ ls -ald /var/lock In my case, where the bug is not reproducible: drwxrwxr-x 3 root uucp 96 2008-05-31 02:13 /var/lock What about you? hwoarang@gentoo.org 2008-06-01 16:28:01 0000 So this is the /etc/group for Group *root* before I execute kmobile tools root:x:0:root Then I execute the kmobiletools Then it asks me for root password I give it to it. It says that my user will be added to groups uucp and root. Then Adding user hwoarang to group root Adding user hwoarang to group uucp And after that cat /etc/group|grep root root:x:0:root,*myuser* Is this behavior normal? ps: ls -ald /var/lock/ drwxrwxr-x 3 root uucp 4096 2008-04-11 08:58 /var/lock/ deathwing00@gentoo.org 2008-06-01 17:28:24 0000 Could you show us the permissions of rfcomm* ttyS* ttyACM* ttyUSB* ircomm* files in /dev? Additionally, could you attach a full log? Thanks. hwoarang@gentoo.org 2008-06-02 12:36:46 0000 ls -la /dev/|grep rfcomm* crw-rw---- 1 root root 216, 0 2008-06-02 15:24 rfcomm0 ls -la /dev/ttyS* crw-rw---- 1 root uucp 4, 64 2008-06-02 18:24 /dev/ttyS0 crw-rw---- 1 root uucp 4, 65 2008-06-02 15:36 /dev/ttyS1 crw-rw---- 1 root uucp 4, 66 2008-06-02 18:24 /dev/ttyS2 crw-rw---- 1 root uucp 4, 67 2008-06-02 18:24 /dev/ttyS3 deathwing00@gentoo.org 2008-06-02 21:19:35 0000 (In reply to comment #9) > ls -la /dev/|grep rfcomm* > crw-rw---- 1 root root 216, 0 2008-06-02 15:24 rfcomm0 You just found the problem. This device does not belong to the appropriate group. hwoarang@gentoo.org 2008-06-03 07:50:42 0000 Indeed. That did the trick Fixed and closed now i guess ;) deathwing00@gentoo.org 2008-06-03 07:55:15 0000 I'd like to have base system verify that these devices are created with the appropriate permissions. Base system herd, could you please confirm? Additionally, I think I will add a permissions check to the ebuild or a permissions autofix to the ebuild so that the application does not add users to the root group. Finally, a bug report upstream asking to implement that functionality internally. vapier@gentoo.org 2008-06-03 13:51:09 0000 anyone who adds random users to the root group should get smacked with a basic permissions howto anyways ;) device permissions is handled by udev ... if there is a central package for it, you should have it include a custom rules.d file. if there isnt, you'll need udev to include an appropriate rule so that it gets uucp group ownership. looking at existing udev rules.d, you'll probably want to just update the rule which sets uucp ownership for ircomm/etc... hwoarang@gentoo.org 2008-06-03 14:09:07 0000 Thats true But how could we add an *EXTRA* udev rule for rfcomm port ? Cause I changed rfcomm port group to uucp and after I rebooted the group changed to root again hwoarang@gentoo.org 2008-06-03 14:15:08 0000 Maybe something like KERNEL=="rfcomm[0-9]", NAME="rfcomm%n" ,GROUP="uucp" zzam@gentoo.org 2008-06-03 18:27:28 0000 (In reply to comment #15) > Maybe something like > > > > KERNEL=="rfcomm[0-9]", NAME="rfcomm%n" ,GROUP="uucp" > This may sure help, but still can be simplified to: KERNEL=="rfcomm[0-9]*", GROUP="uucp" If we are needed to add this to udev-ebuild, I suggest to enhance this rule from /etc/udev/rules.d/65-permissions.rules: KERNEL=="ippp*|isdn*|dcbri*|capi*", GROUP="uucp" But: My system contains /etc/udev/rules.d/70-bluetooth.rules which has this: SUBSYSTEM=="tty", SUBSYSTEMS=="bluetooth", GROUP="uucp" Doesn't this match rfcomm devices? Please add info about versions of kernel, udev and bluez-utils you have on your system. hwoarang@gentoo.org 2008-06-03 18:37:32 0000 The rule I posted works fine for me even after i rebooted Here are my info 2.6.24-gentoo-r8 udev-119 bluez-utils-3.30 zzam@gentoo.org 2008-06-07 08:52:57 0000 Please also attach the output of udevinfo -a -n /dev/rfcomm0 hwoarang@gentoo.org 2008-06-07 12:31:53 0000 Created an attachment (id=155811) udevinfo for rfcomm port zzam@gentoo.org 2008-06-09 19:42:37 0000 udev-122-r1 does now set GROUP="uucp" for rfcomm* devices. deathwing00@gentoo.org 2008-06-10 07:49:38 0000 I think I'll add an extra check to the ebuild. Is it possible to have udev-122-r1 stabilized? rbu@gentoo.org 2008-07-06 22:34:45 0000 udev team, ping. zzam@gentoo.org 2008-07-07 12:05:47 0000 If no big issues show up I vote for stablizing udev-124. rbu@gentoo.org 2008-07-07 15:07:31 0000 No big issues within which timeframe? zzam@gentoo.org 2008-07-29 22:07:01 0000 The only issue I know of with udev-124 is this: http://thread.gmane.org/gmane.linux.hotplug.devel/12858 But it seems this is not yet fixed. Nevertheless I think the time is over, else we forget about this again. :) zzam@gentoo.org 2008-08-14 11:31:12 0000 Is this bug now fixed? The relevant ebuild (kmobiletools-0.5.0_beta3) is marked ~amd64 ~ppc ~x86 and fixed udev-124-r1 is marked amd64 ~ppc x86 rbu@gentoo.org 2008-08-14 12:05:41 0000 This issue only affects the unstable =app-mobilephone/kmobiletools-0.5.0_beta3 and not our stable version =app-mobilephone/kmobiletools-0.4.3.3 The code to add the current user to the groups that are gid of /dev/{rfcomm,ttyS,ttyACM,ttyUSB,ircomm}* /var/lock seems to have been added in the 0.5 series. With udev setting proper group rules for all of these devices, this issue is fixed when all arches have stabled =sys-fs/udev-124-r1 per bug 233790. We do not need the kmobiletools-0.5.0_beta3 stable, and this issue will not result in a GLSA since it did not affect stable ebuilds. Matthias, thanks for getting udev fixed and stable, and sorry for Security's lack of communication the last days. rbu@gentoo.org 2008-08-14 12:15:09 0000 For what it's worth, this is not a security issue, because no trust boundaries are crossed. The user has to provide the root password to acquire being added to the root group, and there is no way to force this without the password. It is an unexpected and undesired behavior, and therefore a bug in udev/kmobiletools. Since we are stabling udev in the other bug, and there is nothing else to do for this bug, I'll close it FIXED. Thanks to everyone for the feedback. 155811 2008-06-07 12:31 0000 udevinfo for rfcomm port udevinfo.txt text/plain ClVkZXZpbmZvIHN0YXJ0cyB3aXRoIHRoZSBkZXZpY2Ugc3BlY2lmaWVkIGJ5IHRoZSBkZXZwYXRo IGFuZCB0aGVuCndhbGtzIHVwIHRoZSBjaGFpbiBvZiBwYXJlbnQgZGV2aWNlcy4gSXQgcHJpbnRz IGZvciBldmVyeSBkZXZpY2UKZm91bmQsIGFsbCBwb3NzaWJsZSBhdHRyaWJ1dGVzIGluIHRoZSB1 ZGV2IHJ1bGVzIGtleSBmb3JtYXQuCkEgcnVsZSB0byBtYXRjaCwgY2FuIGJlIGNvbXBvc2VkIGJ5 IHRoZSBhdHRyaWJ1dGVzIG9mIHRoZSBkZXZpY2UKYW5kIHRoZSBhdHRyaWJ1dGVzIGZyb20gb25l IHNpbmdsZSBwYXJlbnQgZGV2aWNlLgoKICBsb29raW5nIGF0IGRldmljZSAnL2NsYXNzL3R0eS9y ZmNvbW0wJzoKICAgIEtFUk5FTD09InJmY29tbTAiCiAgICBTVUJTWVNURU09PSJ0dHkiCiAgICBE UklWRVI9PSIiCiAgICBBVFRSe2Rldn09PSIyMTY6MCIKICAgIEFUVFJ7YWRkcmVzc309PSIwMDox NjpCODpDNjpFMzo0MCIKICAgIEFUVFJ7Y2hhbm5lbH09PSIxIgoK