Re: User and groups justification (was Re: group nvram)
On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote: On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it wrote: I would prefer any new information to be added there instead, since the files above are available offline as well. Does not forbid to add to wiki in order to ease writing :) I agree we should sync the offline file. If you do so please bear in mind that doc/* in the base-passwd package is licensed GPL-2 and Debian wiki pages have no automatic explicit copyright exceptions (i.e. default to all rights reserved). See http://wiki.debian.org/Maintainers for an example of how to specify an explicit license for a new page (and the linked http://wiki.debian.org/DebianWiki/LicencingTerms for context and history) -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: User and groups justification (was Re: group nvram)
On Fri, Mar 20, 2009 at 1:13 PM, Jon Dowland jon+debian-de...@alcopop.org wrote: On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote: On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it wrote: I would prefer any new information to be added there instead, since the files above are available offline as well. Does not forbid to add to wiki in order to ease writing :) I agree we should sync the offline file. If you do so please bear in mind that doc/* in the base-passwd package is licensed GPL-2 and Debian wiki pages have no automatic explicit copyright exceptions (i.e. default to all rights reserved). See http://wiki.debian.org/Maintainers for an example of how to specify an explicit license for a new page (and the linked http://wiki.debian.org/DebianWiki/LicencingTerms for context and history) Done. Thank you Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Mar 19, Steve Langasek vor...@debian.org wrote: No, they should not. The system groups referenced by udev should instead always be present in /etc/group. Correct. However, I wonder if Marco isn't arguing on the basis of old information; Me too, the maintainers of the relevant packages are encouraged to provide fresh information. lookups for LDAP at boot time should not result in long timeouts, and it's a bug in nss_ldap/libldap if they do - a bug which I thought had been addressed by now. On Mar 19, Stephen Gran sg...@debian.org wrote: Or, possibly better, the udev rules for groups dynamically added by other packages should be moved to those other packages. In general, I I am considering (a mix of) this option as well. like that better than dropping groups from the system on the basis of either a random change in some other distribution or not knowing whether In every other distribution actually. or not they're still useful. Obviously (?) I will remove a group only if it is clear that it is not useful. -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
Josselin Mouette wrote: Le jeudi 19 mars 2009 à 11:09 +0100, Marco d'Itri a écrit : How exactly? The problem is that these groups are referenced in the udev configuration but do not exist, and this causes problmes at boot time with systems using LDAP. You mean, systems using only LDAP and not the local /etc/group? It looks to me that such setups are broken. Either they use /etc/group, either they put these groups in their LDAP, but we can’t suddently start supporting systems where important system groups are missing. In case its not clear, he means groups that are referenced from udev, but are not defined in /etc/group. So, on boot, the NSS resolver tries to find the group in /etc/group and this fails. The NSS resolver then tries to find the group in LDAP, but surprise, surprise, the LDAP server doesn't respond. Keep waiting, it has to respond soon... No answer. Lets try again... wait for it... When of course the reason that there is no response is because udev starts first, before networking or slapd is started. So you get all these silly errors displaying on screen for what is a normal condition. If the timeouts are too large, it also can delay the boot. Significantly. (supposedly libnss-ldapd - based on the description - is suppose to solve this also - not sure how - I haven't been able to get it working entirely satisfactorily). -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Steve Langasek wrote: However, I wonder if Marco isn't arguing on the basis of old information; lookups for LDAP at boot time should not result in long timeouts, and it's a bug in nss_ldap/libldap if they do - a bug which I thought had been addressed by now. It still results in a number ugly messages when booting a Lenny system up. Even if ldap is second in the list. -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
m...@linux.it (Marco d'Itri) wrote: Hi, Scanner is useful, imagine I work in a company working on a secret project. One of the computer has a scanner. Do you wnat to give scanning right to the internship student ? No, I want to give access to the raw scanner device only to its own driver-daemon. I do not know if SCSI scanners already work this way or not. Current scheme for scanners is as follows: - user access: device is group scanner - saned access: device is group saned - user AND saned: either put the saned user in the scanner group, or make the device saned:scanner. USB and SCSI scanners are handled the same way. So to reiterate what I wrote already, if you want to get rid of that in the rules shipped with udev, that's fine by me; libsane will take care of it, it'll be in the next upstream release anyway. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Le mercredi 18 mars 2009 à 19:13 +0100, Marco d'Itri a écrit : fuse (I have no idea about how FUSE works) Then why break it? It’s very useful to be able to restrict the list of users allowed to use it. OTOH, given how it works, it would be really useful to make it use D-Bus so that we’d have more flexibility with permissions (but keeping a group around would be better anyway). rdma (infiniband devices) The security implications of accessing a RDMA device are far from trivial, so the same reasoning applies. You need to be able to lock down the device to a class of users, and Unix groups are currently the simplest approach. The other major reason to do this is that non-standard groups which are not in /etc/groups break some systems which use LDAP. Once was thrown the idea to prefix all system groups with “Debian-”. This solves this specific problem in a much better way. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: group nvram
On Mar 19, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: It is the same probleme with floppy, tty and disk group. No, it's not. They should add this group to their ldap database. At least it should This would not change anything. be documented that debian system need this group. BTW redhat has also rdma, fuse, kvm group. And recently removed them from the udev rules. If you have no clue about the issue being discussed you have no obligation to partecipate to the thread, you know? -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
On Tue, Mar 17, 2009 at 11:42:52AM +0100, Marco d'Itri wrote: Users must not be in specific groups to access hardware, this is broken and insecure. I was just about to reanimate my previous thread on better group handling for squeeze, I think I'll put together a wiki page trying to summarize the situation and options now. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Thu, Mar 19, 2009 at 11:09 AM, Marco d'Itri m...@linux.it wrote: On Mar 19, Josselin Mouette j...@debian.org wrote: Once was thrown the idea to prefix all system groups with ???Debian-???. One of the most stupid ideas which have ever been inflicted on the project. This solves this specific problem in a much better way. How exactly? The problem is that these groups are referenced in the udev configuration but do not exist, and this causes problmes at boot time with systems using LDAP. It is the same probleme with floppy, tty and disk group. But if the collective opinion of the project is that the issue does not exist then I will happily close bugs like #516149 and tell users to live with it. Please advise. They should add this group to their ldap database. At least it should be documented that debian system need this group. BTW redhat has also rdma, fuse, kvm group. Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Mar 19, Josselin Mouette j...@debian.org wrote: Once was thrown the idea to prefix all system groups with ???Debian-???. One of the most stupid ideas which have ever been inflicted on the project. This solves this specific problem in a much better way. How exactly? The problem is that these groups are referenced in the udev configuration but do not exist, and this causes problmes at boot time with systems using LDAP. But if the collective opinion of the project is that the issue does not exist then I will happily close bugs like #516149 and tell users to live with it. Please advise. -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
Le jeudi 19 mars 2009 à 11:09 +0100, Marco d'Itri a écrit : How exactly? The problem is that these groups are referenced in the udev configuration but do not exist, and this causes problmes at boot time with systems using LDAP. You mean, systems using only LDAP and not the local /etc/group? It looks to me that such setups are broken. Either they use /etc/group, either they put these groups in their LDAP, but we can’t suddently start supporting systems where important system groups are missing. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: group nvram
On Mar 19, Josselin Mouette j...@debian.org wrote: How exactly? The problem is that these groups are referenced in the udev configuration but do not exist, and this causes problmes at boot time with systems using LDAP. You mean, systems using only LDAP and not the local /etc/group? No. It looks to me that such setups are broken. Either they use /etc/group, either they put these groups in their LDAP, but we can???t suddently start supporting systems where important system groups are missing. They are not important system groups, or they would be created by base-passwd. -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
Le jeudi 19 mars 2009 à 15:30 +0100, Marco d'Itri a écrit : It looks to me that such setups are broken. Either they use /etc/group, either they put these groups in their LDAP, but we can???t suddently start supporting systems where important system groups are missing. They are not important system groups, or they would be created by base-passwd. A group without which a system cannot boot looks pretty important to me, regardless of which package introduced it. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: group nvram
On Wed, Mar 18, 2009 at 07:13:22PM +0100, Marco d'Itri wrote: This is the complete list of groups which I'd rather stop using: rdma (infiniband devices) is there any alternative way to restrict access to infiniband without this? -- c u henning -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Mar 19, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Moreover I respectfully disagree with you.? Permission on device file Ignorance is not a point of view. -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
On Thu, Mar 19, 2009 at 10:59 AM, Marco d'Itri m...@linux.it wrote: On Mar 19, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: It is the same probleme with floppy, tty and disk group. No, it's not. They should add this group to their ldap database. At least it should This would not change anything. be documented that debian system need this group. BTW redhat has also rdma, fuse, kvm group. And recently removed them from the udev rules. If you have no clue about the issue being discussed you have no obligation to partecipate to the thread, you know? First I was not offencive with you, so you please could you keep a nice and peaceful thread. Secondly, I use Unix for a long time, and last time I checked redhat used kvm group. May be I am not up to date as you say, but please keep the thread peaceful. Moreover I respectfully disagree with you.? Permission on device file should be from a security point of view, permission should respect the minimum privileges principle. Therefore daemon using /dev/fuse should be able only to use /dev/kvm and not /dev/fuse. You could note also that for instance Josselin mouette respectfully disagree with you. So please keep this thread quiet. I have the right to disagree with you, and you have the right to think I am a sucker but please keep it private at least. Best regard Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Thu, Mar 19, 2009 at 2:39 PM, Henning Glawe gla...@debian.org wrote: On Wed, Mar 18, 2009 at 07:13:22PM +0100, Marco d'Itri wrote: This is the complete list of groups which I'd rather stop using: rdma (infiniband devices) is there any alternative way to restrict access to infiniband without this? rdma group has some advantage. I have beginned to document reason under http://wiki.debian.org/SystemGroups You could see for instance that this group is needed in order to update the mlock limit. Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Thu, Mar 19, 2009 at 11:37:59AM +0100, Bastien ROUCARIES wrote: But if the collective opinion of the project is that the issue does not exist then I will happily close bugs like #516149 and tell users to live with it. Please advise. They should add this group to their ldap database. At least it should be documented that debian system need this group. BTW redhat has also rdma, fuse, kvm group. No, they should not. The system groups referenced by udev should instead always be present in /etc/group. However, I wonder if Marco isn't arguing on the basis of old information; lookups for LDAP at boot time should not result in long timeouts, and it's a bug in nss_ldap/libldap if they do - a bug which I thought had been addressed by now. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Le jeudi 19 mars 2009 à 18:23 +0100, Marco d'Itri a écrit : Ignorance is not a point of view. What if you explained *precisely* what is the problem you are seeing with these groups, and the implications? If you keep referring vaguely to discussions happening in other distributions instead, I fail to see how there can be any discussion at all. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: group nvram
This one time, at band camp, Steve Langasek said: On Thu, Mar 19, 2009 at 11:37:59AM +0100, Bastien ROUCARIES wrote: But if the collective opinion of the project is that the issue does not exist then I will happily close bugs like #516149 and tell users to live with it. Please advise. They should add this group to their ldap database. At least it should be documented that debian system need this group. BTW redhat has also rdma, fuse, kvm group. No, they should not. The system groups referenced by udev should instead always be present in /etc/group. Or, possibly better, the udev rules for groups dynamically added by other packages should be moved to those other packages. In general, I like that better than dropping groups from the system on the basis of either a random change in some other distribution or not knowing whether or not they're still useful. However, I wonder if Marco isn't arguing on the basis of old information; lookups for LDAP at boot time should not result in long timeouts, and it's a bug in nss_ldap/libldap if they do - a bug which I thought had been addressed by now. It's fine if ldap comes second in nsswitch, although it's still a bit painful if ldap is first in the group lookup (I don't know whether this is actually still necessary, but some old configurations use it to override system groups). Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: group nvram
Stephen Gran sg...@debian.org writes: Users must not be in specific groups to access hardware, this is broken and insecure. That's the first I've heard that argument - of course you don't give untrusted users access to hardware, but we've always managed access to devices with group membership (lp, dialout, etc). Are you proposing that should change? Well, since lp and dialout access cannot render your machine unbootable, this is indeed possible with nvram, since you can overwrite critical parts of your bios with it. Think of an malicious or buggy program running under your user account doing nasty things. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Steve Langasek wrote: It's certainly far *more* insecure to add users to the kmem group than to the nvram group. Definitely. But I'm not aware of any reason that users need to access /dev/nvram, generally. The only tool I know of that uses this interface is hotkey-setup, which runs a daemon as root to handle polling the nvram state, so the group permissions don't matter. What way use other programs like pidging-blinklight these days? I remember that /dev/nvram was needed to get a blinking keyboard light years ago... not sure what the current way is. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Wed, Mar 18, 2009 at 05:37:49PM +0100, Bernd Zeimetz wrote: But I'm not aware of any reason that users need to access /dev/nvram, generally. The only tool I know of that uses this interface is hotkey-setup, which runs a daemon as root to handle polling the nvram state, so the group permissions don't matter. What way use other programs like pidging-blinklight these days? I remember that /dev/nvram was needed to get a blinking keyboard light years ago... not sure what the current way is. A peek at the source says it uses /proc/acpi/ibm/light. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Mar 18, Steve Langasek vor...@debian.org wrote: A peek at the source says it uses /proc/acpi/ibm/light. Other people told me that they believe that nowadays all modern thinkpads use a kernel driver. This is the complete list of groups which I'd rather stop using: fuse (I have no idea about how FUSE works) kvm (what are the security implications of access to /dev/kvm?) nvram rdma (infiniband devices) scanner (do SCSI scanners still exist? how are they used?) tss (TPM devices, do select users have a need to access them?) The other major reason to do this is that non-standard groups which are not in /etc/groups break some systems which use LDAP. -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
2009/3/18 Marco d'Itri m...@linux.it: This is the complete list of groups which I'd rather stop using: fuse (I have no idea about how FUSE works) Neither do I, I see FUSE helper binary is set suid, and executable only for fuse members, but there could be more AFAIK. It would be a good idea not to mess it up, and wait for someone who actually knows it... kvm (what are the security implications of access to /dev/kvm?) Locking large amounts of memory that can't be swapped out to disk. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote: On Mar 18, Steve Langasek vor...@debian.org wrote: A peek at the source says it uses /proc/acpi/ibm/light. Other people told me that they believe that nowadays all modern thinkpads use a kernel driver. This is the complete list of groups which I'd rather stop using: fuse (I have no idea about how FUSE works) This group is important, fuse could lead to local dos. kvm (what are the security implications of access to /dev/kvm?) Idem local dos due to pinned memory nvram rdma (infiniband devices) scanner (do SCSI scanners still exist? how are they used?) scanner is also used for usb device. tss (TPM devices, do select users have a need to access them?) BTW why do you hate this group? They are here in order to give fine gained privilege, that is the basis of good security. The other major reason to do this is that non-standard groups which are not in /etc/groups break some systems which use LDAP. Add this group to standard ldap. Acces to harware should be limited by policy, and group is a good policy. And a catch all group coulddolocaldos is not really a good policy. Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote: On Mar 18, Steve Langasek vor...@debian.org wrote: A peek at the source says it uses /proc/acpi/ibm/light. Other people told me that they believe that nowadays all modern thinkpads use a kernel driver. This is the complete list of groups which I'd rather stop using: fuse (I have no idea about how FUSE works) kvm (what are the security implications of access to /dev/kvm?) nvram rdma (infiniband devices) scanner (do SCSI scanners still exist? how are they used?) Scanner is useful, imagine I work in a company working on a secret project. One of the computer has a scanner. Do you wnat to give scanning right to the internship student ? Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
m...@linux.it (Marco d'Itri) wrote: Hi, This is the complete list of groups which I'd rather stop using: scanner (do SCSI scanners still exist? how are they used?) Yes, SCSI scanners still exist, and they're still used through /dev/sgX. Actually, all high-volume, high-speed scanners are SCSI. Some have a USB interface too, but it's slower. You can pull that from udev if you wish, as support for SCSI scanners has been added upstream to the udev rules and I can backport that to unstable. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Bastien ROUCARIES wrote: On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote: Scanner is useful, imagine I work in a company working on a secret project. One of the computer has a scanner. Do you wnat to give scanning right to the internship student ? Ack. That's what it the group is used for at one of our customers. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Hi, scanner (do SCSI scanners still exist? how are they used?) Scanner is useful, imagine I work in a company working on a secret project. One of the computer has a scanner. Do you wnat to give scanning right to the internship student ? Marco is specifically referring to the generic SCSI scanners support in the basic udev rules. That can be migrated to libsane. The scanner group is not going away anytime soon. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Wed, 18 Mar 2009, Marco d'Itri wrote: On Mar 18, Steve Langasek vor...@debian.org wrote: A peek at the source says it uses /proc/acpi/ibm/light. Other people told me that they believe that nowadays all modern thinkpads use a kernel driver. A driver which I happen to be the maintainer of ;-) The driver supports every real thinkpad made in the last ten years, including the more common numbered series models still in use (770, 600, 570). Almost-thinkpads (like the thinkpad-sl and the i-series) are unlikely to have a compatible nvram layout anyway, so they don't count. I *do* know of people still using the model 240, and those cannot use the ACPI-based driver at all. But these people usually do NOT run Debian, either. However, if you remove group nvram, please don't go with kmem. Go with root. While PeeCee CMOS-style NVRAM writes can soft-brick a box (you debrick it by clearing the nvram and redoing all your BIOS config), AFAIK kmem access lets you install rootkits or read sensitive data like encryption keys. By using the root group for /dev/nvram, you avoid the trap of people adding users to the kmem group without knowing the consequences. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Tue, 17 Mar 2009, Bernd Zeimetz wrote:
Please do not as it will allow users which need to access Thinkpad-specific
devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
hole in my opinion.
Which are? If you mean people running tpb, tpb is as far as I know,
completely obsolete on anything that can run thinkpad-acpi.
I am honestely curious about it, and I can *do* something about it easily if
there is some functionality missing from thinkpad-acpi that is commonly used
on thinkpads that will run Debian Squeeze.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote: On Mar 18, Steve Langasek vor...@debian.org wrote: A peek at the source says it uses /proc/acpi/ibm/light. Other people told me that they believe that nowadays all modern thinkpads use a kernel driver. This is the complete list of groups which I'd rather stop using: fuse (I have no idea about how FUSE works) This group is important, fuse could lead to local dos. kvm (what are the security implications of access to /dev/kvm?) Idem local dos due to pinned memory nvram rdma (infiniband devices) about this group: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216 Having 0666 permissions would not necessarily be a bad idea, but the consensus among other distributions is to limit RDMA access to an rdma group so that administrators have some control over who gets direct hardware access (even though in theory it is safe for anyone, there is the possibility of untrusted users consuming network bandwidth at least). Also, RDMA often requires increasing the amount of locked memory allowed in /etc/security/limits.conf, and doing that by group rdma is convenient as well. scanner (do SCSI scanners still exist? how are they used?) scanner is also used for usb device. tss (TPM devices, do select users have a need to access them?) BTW why do you hate this group? They are here in order to give fine gained privilege, that is the basis of good security. The other major reason to do this is that non-standard groups which are not in /etc/groups break some systems which use LDAP. Add this group to standard ldap. Acces to harware should be limited by policy, and group is a good policy. And a catch all group coulddolocaldos is not really a good policy. BTW instead of arguing about group and something like this could we create a wiki page on debian wiki about justification of group. Therefore purpose of every system group will documented. With exemple of security concern. Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri m...@linux.it wrote: On Mar 18, Steve Langasek vor...@debian.org wrote: A peek at the source says it uses /proc/acpi/ibm/light. Other people told me that they believe that nowadays all modern thinkpads use a kernel driver. This is the complete list of groups which I'd rather stop using: fuse (I have no idea about how FUSE works) This group is important, fuse could lead to local dos. kvm (what are the security implications of access to /dev/kvm?) Idem local dos due to pinned memory nvram rdma (infiniband devices) about this group: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/256216 Having 0666 permissions would not necessarily be a bad idea, but the consensus among other distributions is to limit RDMA access to an rdma group so that administrators have some control over who gets direct hardware access (even though in theory it is safe for anyone, there is the possibility of untrusted users consuming network bandwidth at least). Also, RDMA often requires increasing the amount of locked memory allowed in /etc/security/limits.conf, and doing that by group rdma is convenient as well. scanner (do SCSI scanners still exist? how are they used?) scanner is also used for usb device. tss (TPM devices, do select users have a need to access them?) BTW why do you hate this group? They are here in order to give fine gained privilege, that is the basis of good security. The other major reason to do this is that non-standard groups which are not in /etc/groups break some systems which use LDAP. Add this group to standard ldap. Acces to harware should be limited by policy, and group is a good policy. And a catch all group coulddolocaldos is not really a good policy. BTW instead of arguing about group and something like this could we create a wiki page on debian wiki about justification of group. Therefore purpose of every system group will documented. With exemple of security concern. Done under http://wiki.debian.org/SystemGroups Please contribute Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Julien BLACHE wrote: m...@linux.it (Marco d'Itri) wrote: Hi, This is the complete list of groups which I'd rather stop using: scanner (do SCSI scanners still exist? how are they used?) Yes, SCSI scanners still exist, and they're still used through /dev/sgX. Actually, all high-volume, high-speed scanners are SCSI. Some have a USB interface too, but it's slower. I also know some fancy damn expensive scanners with firewire, but I doubt they're supported in sane - unfortunately. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Bernd Zeimetz be...@bzed.de wrote: Hi, Yes, SCSI scanners still exist, and they're still used through /dev/sgX. Actually, all high-volume, high-speed scanners are SCSI. Some have a USB interface too, but it's slower. I also know some fancy damn expensive scanners with firewire, but I doubt they're supported in sane - unfortunately. True. There's not been a lot of interest for the FireWire scanners. Though I do believe those scanners actually do SCSI over FireWire, but never checked that out. That'd be the most sensible thing to do. That can be verified pretty easily, if the scanner uses SCSI commands (or encapsulation) on its USB interface, you can bet the FireWire interface just does SCSI. I wish I had time to try that out when I had access to an A3 Epson scanner with USB FireWire. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
User and groups justification (was Re: group nvram)
Hi there! On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote: On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: BTW instead of arguing about group and something like this could we create a wiki page on debian wiki about justification of group. Therefore purpose of every system group will documented. With exemple of security concern. Done under http://wiki.debian.org/SystemGroups Please contribute Do you know that a similar document is already installed on any Debian system (provided by the base-passwd package)? /usr/share/doc/base-passwd/user-and-groups.html /usr/share/doc/base-passwd/user-and-groups.txt.gz I would prefer any new information to be added there instead, since the files above are available offline as well. Thx, bye, Gismo / Luca pgpfvqJnViYXv.pgp Description: PGP signature
Re: group nvram
On Mar 18, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Scanner is useful, imagine I work in a company working on a secret project. One of the computer has a scanner. Do you wnat to give scanning right to the internship student ? No, I want to give access to the raw scanner device only to its own driver-daemon. I do not know if SCSI scanners already work this way or not. -- ciao, Marco signature.asc Description: Digital signature
Re: User and groups justification (was Re: group nvram)
On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it wrote: Hi there! On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote: On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: BTW instead of arguing about group and something like this could we create a wiki page on debian wiki about justification of group. Therefore purpose of every system group will documented. With exemple of security concern. Done under http://wiki.debian.org/SystemGroups Please contribute Do you know that a similar document is already installed on any Debian system (provided by the base-passwd package)? I forget :S /usr/share/doc/base-passwd/user-and-groups.html /usr/share/doc/base-passwd/user-and-groups.txt.gz I would prefer any new information to be added there instead, since the files above are available offline as well. Does not forbid to add to wiki in order to ease writing :) I agree we should sync the offline file. Thx, bye, Gismo / Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
I'd like to chime in with the general concern that the proposal to remove a bunch of groups from udev seems under-baked and that the current groups have value. I definitely would like to see the tss (tpm) group remain along with the kvm and fuse groups. I think scanner is important as well. I can understand the argument for getting rid of nvram. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
This one time, at band camp, Marco d'Itri said: Unless somebody will have persuasive objections I will change it to group kmem in a future udev upgrade. This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl utilities to work, you currently need to be in group nvram. Making that equivalent to kmem seems unnecessarily broad to me. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: group nvram
Hi Marco, On Dienstag, 17. März 2009, Marco d'Itri wrote: Unless somebody will have persuasive objections I will change it to group kmem in a future udev upgrade. Are you planning to file bugs against affected packages to help the transition? How will upgrades (from lenny, etch, ...) be handled? regards, Holger signature.asc Description: This is a digitally signed message part.
Re: group nvram
On Mar 17, Stephen Gran sg...@debian.org wrote: This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl I think so. The rationale for this change is harmonization with all other distributions. utilities to work, you currently need to be in group nvram. Making that equivalent to kmem seems unnecessarily broad to me. Users must not be in specific groups to access hardware, this is broken and insecure. On Mar 17, Holger Levsen hol...@layer-acht.org wrote: Are you planning to file bugs against affected packages to help the transition? I do not know which packages are affected, if any. How will upgrades (from lenny, etch, ...) be handled? This is up to the maintainers of the affected package. -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
On Tue, Mar 17, 2009 at 11:42:52AM +0100, Marco d'Itri m...@linux.it wrote: On Mar 17, Stephen Gran sg...@debian.org wrote: This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl I think so. The rationale for this change is harmonization with all other distributions. utilities to work, you currently need to be in group nvram. Making that equivalent to kmem seems unnecessarily broad to me. Users must not be in specific groups to access hardware, this is broken and insecure. Like e.g. the audio and video groups ? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
This one time, at band camp, Marco d'Itri said: On Mar 17, Stephen Gran sg...@debian.org wrote: This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl utilities to work, you currently need to be in group nvram. Making that equivalent to kmem seems unnecessarily broad to me. Users must not be in specific groups to access hardware, this is broken and insecure. That's the first I've heard that argument - of course you don't give untrusted users access to hardware, but we've always managed access to devices with group membership (lp, dialout, etc). Are you proposing that should change? Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: group nvram
On Mar 17, Stephen Gran sg...@debian.org wrote: That's the first I've heard that argument - of course you don't give This is weird, because it has been around for quite a long time. E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash untrusted users access to hardware, but we've always managed access to devices with group membership (lp, dialout, etc). Are you proposing that should change? The rest of the Linux world is: http://dualstack.ipv6-exp.l.google.com/search?q=policykit . -- ciao, Marco signature.asc Description: Digital signature
Re: group nvram
This one time, at band camp, Marco d'Itri said: On Mar 17, Stephen Gran sg...@debian.org wrote: That's the first I've heard that argument - of course you don't give This is weird, because it has been around for quite a long time. E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash Since you can't do that unless you're already in group audio, I'm not sure what you're trying to say. The part of my mail you cut did say that you don't give untrusted users access to these groups. untrusted users access to hardware, but we've always managed access to devices with group membership (lp, dialout, etc). Are you proposing that should change? The rest of the Linux world is: http://dualstack.ipv6-exp.l.google.com/search?q=policykit . I am less than impressed with more solutions that depend on dbus. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: group nvram
Le mardi 17 mars 2009 à 12:26 +0100, Marco d'Itri a écrit : untrusted users access to hardware, but we've always managed access to devices with group membership (lp, dialout, etc). Are you proposing that should change? The rest of the Linux world is: http://dualstack.ipv6-exp.l.google.com/search?q=policykit . Which doesn’t work for audio devices given the poor architecture of audio APIs. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: group nvram
Marco d'Itri wrote: On Mar 17, Stephen Gran sg...@debian.org wrote: That's the first I've heard that argument - of course you don't give This is weird, because it has been around for quite a long time. E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash This argument makes as much sense as cp /bin/bash .; chgrp md bash; chmod g+s bash Either you're member of a group, then you're allowed to mess with the rights of the group, or you're not. untrusted users access to hardware, but we've always managed access to devices with group membership (lp, dialout, etc). Are you proposing that should change? The rest of the Linux world is: http://dualstack.ipv6-exp.l.google.com/search?q=policykit . Which means I need to run some weird agent to be able to access my printer, serial ports and similar devices? ironyThat makes so much sense.../irony. Please do not try to change common and working things, just because somebody thinks there's a fance new piece of code which could handle it better. Remember, there're small machines with limited memory running Debian, where you neither want to waste memory with an agent nor you want to run everything as root. The idea behind policykit is not bad, but it should be introduced with care and not by breaking well working ways of handling access. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Marco d'Itri wrote:
Unless somebody will have persuasive objections I will change it to
group kmem in a future udev upgrade.
Please do not as it will allow users which need to access Thinkpad-specific
devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
hole in my opinion.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
2009/3/17 Marco d'Itri m...@linux.it: E.g. cp /bin/bash .; chgrp audio bash; chmod g+s bash I don't need to point out that this example doesn't make sense, do I? The rest of the Linux world is: http://dualstack.ipv6-exp.l.google.com/search?q=policykit . From policykit page: PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. Oh dear yes, another hal-like crap piece of software is just what we need the whole system to rely on. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
Le mardi 17 mars 2009 à 14:51 +0100, Luca Niccoli a écrit : From policykit page: PolicyKit is specifically targeting applications in rich desktop environments on multi-user UNIX-like operating systems. Oh dear yes, another hal-like crap piece of software is just what we need the whole system to rely on. Marco pointed at the wrong piece of software. PolicyKit is meant for GUIs that authenticate users to grant them extra privileges. The one that helps dealing with hardware without the need for groups is ConsoleKit, which allows to grant D-Bus privileges based on who is physically using the machine. Applications making use of such features only need to depend on D-Bus. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: group nvram
On Mar 17, Bernd Zeimetz be...@bzed.de wrote:
Please do not as it will allow users which need to access Thinkpad-specific
devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
Other distributions apparently solved this.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: group nvram
On Tue, Mar 17, 2009 at 05:12:36PM +0100, Marco d'Itri wrote:
On Mar 17, Bernd Zeimetz be...@bzed.de wrote:
Please do not as it will allow users which need to access Thinkpad-specific
devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge
security
Other distributions apparently solved this.
Other distributions apparently do not have Marco d'Itri as developer. Do
you propose we should harmonize on that as well?
cheers,
Michael
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: group nvram
On Tue, Mar 17, 2009 at 11:42:52AM +0100, Marco d'Itri wrote: On Mar 17, Stephen Gran sg...@debian.org wrote: This is the thinkpad /dev/nvram stuff, right? I thought for some tpctl I think so. The rationale for this change is harmonization with all other distributions. On its own, that's a fairly uninteresting rationale where system groups are concerned. utilities to work, you currently need to be in group nvram. Making that equivalent to kmem seems unnecessarily broad to me. Users must not be in specific groups to access hardware, this is broken and insecure. No, it's only broken if the users are added to the groups on login with the assumption that the permissions can be removed at the end of the session. It's certainly far *more* insecure to add users to the kmem group than to the nvram group. But I'm not aware of any reason that users need to access /dev/nvram, generally. The only tool I know of that uses this interface is hotkey-setup, which runs a daemon as root to handle polling the nvram state, so the group permissions don't matter. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
