Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Mon, Mar 14, 2011 at 10:26:05PM -0400, James Bottomley wrote: > On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote: > > > Vasiliy Kulikov (20): > > > mach-ux500: mbox-db5500: world-writable sysfs fifo file > > > leds: lp5521: world-writable sysfs engine* files > > > leds: lp5523: world-writable engine* sysfs files > > > misc: ep93xx_pwm: world-writable sysfs files > > > rtc: rtc-ds1511: world-writable sysfs nvram file > > > scsi: aic94xx: world-writable sysfs update_bios file > > > scsi: iscsi: world-writable sysfs priv_sess file > > > > These are still not merged :( > > OK, so I've not been tracking where we are in the dizzying ride on > security systems. However, I thought we landed up in the privilege > separation arena using capabilities. That means that world writeable > files aren't necessarily a problem as long as the correct capabilities > checks are in place, right? There are no capability checks on sysfs files right now, so these all need to be fixed. thanks, greg k-h -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Tue, 2011-03-15 at 19:08 +0300, Vasiliy Kulikov wrote: > On Tue, Mar 15, 2011 at 07:50 -0400, James Bottomley wrote: > > 1. Did anyone actually check for capabilities before assuming world > > writeable files were wrong? > > I didn't check all these files as I haven't got these hardware :-) You don't need the hardware to check ... the question becomes is a capabilities test sitting in the implementation or not. > But > as I can "chmod a+w" all sysfs files on my machine and they all become > sensible to nonroot writes, I suppose there is nothing preventing > nonroot users from writing to these buggy sysfs files. As you can see, > there are no capable() checks in these drivers in open() or write(). > > > 2. Even if there aren't any capabilities checks in the implementing > > routines, should there be (are we going the separated > > capabilities route vs the monolithic root route)? > > IMO, In any case old good DAC security model must not be obsoleted just > because someone thinks that MAC or anything else is more convenient for > him. If sysfs is implemented via filesystem then it must support POSIX > permissions semantic. MAC is very good in _some_ cases, but not instead > of DAC. Um, I'm not sure that's even an issue. capabilities have CAP_ADMIN which is precisely the same check as owner == root. We use this a lot because ioctls ignore the standard unix DAC model. James -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Tue, 2011-03-15 at 07:18 -0700, Greg KH wrote: > On Tue, Mar 15, 2011 at 07:50:28AM -0400, James Bottomley wrote: > > On Mon, 2011-03-14 at 20:09 -0700, Greg KH wrote: > > > There are no capability checks on sysfs files right now, so these all > > > need to be fixed. > > > > That statement is true but irrelevant, isn't it? There can't be > > capabilities within sysfs files because the system that does them has no > > idea what the capabilities would be. If there were capabilities checks, > > they'd have to be in the implementing routines. > > Ah, you are correct, sorry for the misunderstanding. > > > I think the questions are twofold: > > > > 1. Did anyone actually check for capabilities before assuming world > > writeable files were wrong? > > I do not think so as the majority (i.e. all the ones that I looked at) > did no such checks. OK, as long as someone checked, I'm happy. > > 2. Even if there aren't any capabilities checks in the implementing > > routines, should there be (are we going the separated > > capabilities route vs the monolithic root route)? > > I think the general consensus is that we go the monolithic root route > for sysfs files in that we do not allow them to be world writable. > > Do you have any exceptions that you know of that do these checks? Heh, I didn't call our security vacillations a dizzying ride for nothing. I know the goal once was to try to run a distro without root daemons (which is what required the capabilities stuff). I'm actually trying to avoid the issue ... I just want to make sure that people who care aren't all moving in different directions. James -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 00/20] world-writable files in sysfs and debugfs
On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote: > > Vasiliy Kulikov (20): > > mach-ux500: mbox-db5500: world-writable sysfs fifo file > > leds: lp5521: world-writable sysfs engine* files > > leds: lp5523: world-writable engine* sysfs files > > misc: ep93xx_pwm: world-writable sysfs files > > rtc: rtc-ds1511: world-writable sysfs nvram file > > scsi: aic94xx: world-writable sysfs update_bios file > > scsi: iscsi: world-writable sysfs priv_sess file > > These are still not merged :( OK, so I've not been tracking where we are in the dizzying ride on security systems. However, I thought we landed up in the privilege separation arena using capabilities. That means that world writeable files aren't necessarily a problem as long as the correct capabilities checks are in place, right? James -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Mon, 2011-03-14 at 20:09 -0700, Greg KH wrote: > On Mon, Mar 14, 2011 at 10:26:05PM -0400, James Bottomley wrote: > > On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote: > > > > Vasiliy Kulikov (20): > > > > mach-ux500: mbox-db5500: world-writable sysfs fifo file > > > > leds: lp5521: world-writable sysfs engine* files > > > > leds: lp5523: world-writable engine* sysfs files > > > > misc: ep93xx_pwm: world-writable sysfs files > > > > rtc: rtc-ds1511: world-writable sysfs nvram file > > > > scsi: aic94xx: world-writable sysfs update_bios file > > > > scsi: iscsi: world-writable sysfs priv_sess file > > > > > > These are still not merged :( > > > > OK, so I've not been tracking where we are in the dizzying ride on > > security systems. However, I thought we landed up in the privilege > > separation arena using capabilities. That means that world writeable > > files aren't necessarily a problem as long as the correct capabilities > > checks are in place, right? > > There are no capability checks on sysfs files right now, so these all > need to be fixed. That statement is true but irrelevant, isn't it? There can't be capabilities within sysfs files because the system that does them has no idea what the capabilities would be. If there were capabilities checks, they'd have to be in the implementing routines. I think the questions are twofold: 1. Did anyone actually check for capabilities before assuming world writeable files were wrong? 2. Even if there aren't any capabilities checks in the implementing routines, should there be (are we going the separated capabilities route vs the monolithic root route)? James -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Tue, Mar 15, 2011 at 07:50:28AM -0400, James Bottomley wrote: > On Mon, 2011-03-14 at 20:09 -0700, Greg KH wrote: > > On Mon, Mar 14, 2011 at 10:26:05PM -0400, James Bottomley wrote: > > > On Sat, 2011-03-12 at 23:23 +0300, Vasiliy Kulikov wrote: > > > > > Vasiliy Kulikov (20): > > > > > mach-ux500: mbox-db5500: world-writable sysfs fifo file > > > > > leds: lp5521: world-writable sysfs engine* files > > > > > leds: lp5523: world-writable engine* sysfs files > > > > > misc: ep93xx_pwm: world-writable sysfs files > > > > > rtc: rtc-ds1511: world-writable sysfs nvram file > > > > > scsi: aic94xx: world-writable sysfs update_bios file > > > > > scsi: iscsi: world-writable sysfs priv_sess file > > > > > > > > These are still not merged :( > > > > > > OK, so I've not been tracking where we are in the dizzying ride on > > > security systems. However, I thought we landed up in the privilege > > > separation arena using capabilities. That means that world writeable > > > files aren't necessarily a problem as long as the correct capabilities > > > checks are in place, right? > > > > There are no capability checks on sysfs files right now, so these all > > need to be fixed. > > That statement is true but irrelevant, isn't it? There can't be > capabilities within sysfs files because the system that does them has no > idea what the capabilities would be. If there were capabilities checks, > they'd have to be in the implementing routines. Ah, you are correct, sorry for the misunderstanding. > I think the questions are twofold: > > 1. Did anyone actually check for capabilities before assuming world > writeable files were wrong? I do not think so as the majority (i.e. all the ones that I looked at) did no such checks. > 2. Even if there aren't any capabilities checks in the implementing > routines, should there be (are we going the separated > capabilities route vs the monolithic root route)? I think the general consensus is that we go the monolithic root route for sysfs files in that we do not allow them to be world writable. Do you have any exceptions that you know of that do these checks? thanks, greg k-h -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs
On Sat, 12 Mar 2011 23:23:06 +0300 Vasiliy Kulikov wrote: > > Vasiliy Kulikov (20): > > mach-ux500: mbox-db5500: world-writable sysfs fifo file > > leds: lp5521: world-writable sysfs engine* files > > leds: lp5523: world-writable engine* sysfs files > > misc: ep93xx_pwm: world-writable sysfs files > > rtc: rtc-ds1511: world-writable sysfs nvram file > > scsi: aic94xx: world-writable sysfs update_bios file > > scsi: iscsi: world-writable sysfs priv_sess file > > These are still not merged :( I grabbed them and shall merge some and send others at relevant maintainers, thanks. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 00/20] world-writable files in sysfs and debugfs
The search was made with trivial shell commands: find | xargs grep S_IWUGO find | xargs grep S_IWOTH I didn't precisely investigate how exactly one may damage the system/hardware because of issues number, maybe the harm is very limited in case of some of these drivers. One suspicious file is ./staging/speakup/speakup.h, but it explitly calls macros as world-writable. I didn't check what speakup's world-writable files provide because it requires some knowledge about the hardware. Vasiliy Kulikov (20): mach-omap2: mux: world-writable debugfs files mach-omap2: pm: world-writable debugfs timer files mach-omap2: smartreflex: world-writable debugfs voltage files mach-ux500: mbox-db5500: world-writable sysfs fifo file leds: lp5521: world-writable sysfs engine* files leds: lp5523: world-writable engine* sysfs files video: sn9c102: world-wirtable sysfs files mfd: ab3100: world-writable debugfs *_priv files mfd: ab3500: world-writable debugfs register-* files mfd: ab8500: world-writable debugfs register-* files misc: ep93xx_pwm: world-writable sysfs files net: can: at91_can: world-writable sysfs files net: can: janz-ican3: world-writable sysfs termination file platform: x86: acer-wmi: world-writable sysfs threeg file platform: x86: asus_acpi: world-writable procfs files platform: x86: tc1100-wmi: world-writable sysfs wireless and jogdial files rtc: rtc-ds1511: world-writable sysfs nvram file scsi: aic94xx: world-writable sysfs update_bios file scsi: iscsi: world-writable sysfs priv_sess file fs: ubifs: world-writable debugfs dump_* files arch/arm/mach-omap2/mux.c |2 +- arch/arm/mach-omap2/pm-debug.c |8 arch/arm/mach-omap2/smartreflex.c |4 ++-- arch/arm/mach-ux500/mbox-db5500.c |2 +- drivers/leds/leds-lp5521.c | 14 +++--- drivers/leds/leds-lp5523.c | 20 ++-- drivers/media/video/sn9c102/sn9c102_core.c |6 +++--- drivers/mfd/ab3100-core.c |4 ++-- drivers/mfd/ab3550-core.c |6 +++--- drivers/mfd/ab8500-debugfs.c |6 +++--- drivers/misc/ep93xx_pwm.c |6 +++--- drivers/net/can/at91_can.c |2 +- drivers/net/can/janz-ican3.c |2 +- drivers/platform/x86/acer-wmi.c|2 +- drivers/platform/x86/asus_acpi.c |8 +--- drivers/platform/x86/tc1100-wmi.c |2 +- drivers/rtc/rtc-ds1511.c |2 +- drivers/scsi/aic94xx/aic94xx_init.c|2 +- drivers/scsi/scsi_transport_iscsi.c|2 +- fs/ubifs/debug.c |6 +++--- 20 files changed, 50 insertions(+), 56 deletions(-) -- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 00/20] world-writable files in sysfs and debugfs
Thanks, I've applied the x86 platform driver ones. -- Matthew Garrett | mj...@srcf.ucam.org -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [rtc-linux] [PATCH 00/20] world-writable files in sysfs and debugfs
2011/2/4 Vasiliy Kulikov : > The search was made with trivial shell commands: > > find | xargs grep S_IWUGO > find | xargs grep S_IWOTH We only use our debugfs entries as root so it shouldn't matter much, this is way better, thanks for fixing. > mach-ux500: mbox-db5500: world-writable sysfs fifo file > mfd: ab3100: world-writable debugfs *_priv files > mfd: ab3500: world-writable debugfs register-* files > mfd: ab8500: world-writable debugfs register-* files Acked-by: Linus Walleij For these. Yours, Linus Walleij -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
