Re: SuperUser permission for the Driver??
But /etc/udev/rules.d is executed as root, so your activity would still need excessive privilege. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
shivaprasad wrote: But I got one more question for you, now to install the activity and having it running I have to copy the rules file into /etc/udev/rules.d folder. How can I do this while installing the activity itself. ( I need to make sure that when I unzip my activity .xo file the rules file lands in the /etc/udev/rules.d folder) james wrote: But /etc/udev/rules.d is executed as root, so your activity would still need excessive privilege. unless i'm misunderstanding, it seems to me that this is a problem that needs to be solved -- there are lots of little user-oriented USB devices that an activity might like to have access to -- serial, GPS, cameras, etc. just as we make USB storage devices accessible to the user, we need to allow for other types of h/w accessories. (i have an activity that needs this as well, if it's to be useable without unix commandline knowledge.) paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjw/AACgkQUJT6e6HFtqQlSgCfbDujhumR3cmtT/MpEH8qQidC cYEAn0atipCHDcuYjAIvS/E6IpxD0Ktb =WJse -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
benjamin m. schwartz wrote: Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. perhaps, but i have trouble believing that no school will ever have any loaner, or classroom shared peripherals that the students may not own, but will still need to be able to use. (but perhaps most of these will fall into some well-known categores -- e.g., USB serial adapters. and we could maybe support them with a canned udev entry?) There is a planned design to allow the user to grant extra privileges to different Activities, reference? paul but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
... to install the activity and having it running I have to copy the rules file into /etc/udev/rules.d folder. The preferred short answer seems to be NO. But if an Activity (application) *does* need something to be put into the operating system, should the Sugar environment provide a way to add that ? A benefit (to people who manipulate their systems) of putting add-on Activities into /home/olpc was to make them independent of an 'olpc-update' which replaced the operating system. One solution to the problem above would be to create TWO packages, one (.xo) to install the user-permissions material (done once), and the second (.rpm ?) to install the system modifications (done every time the system is replaced). [Etoys already supplies two such packages.] An RPM is static, and platform/version dependent. Ought the Sugar environment provide an intelligent facility which would 'hook/unhook' drivers [and objects on removable devices] into the running system (e.g., to add/remove Sugar Activities) ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
Benjamin M. Schwartz writes: There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. VMWare-1.xo It's the only way to get usable performance on a system that doesn't have hardware virtualization support. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] SuperUser permission for the Driver??
On Thu, 26 Jun 2008, Deepak Saxena wrote: On Jun 25 2008, at 14:01, Carl-Daniel Hailfinger was caught saying: On 25.06.2008 08:07, Michael Stone wrote: We have an activity that wants superuser privilege in order to poke kernel memory. Hello? Please take the poor activity out back and shoot it. No activity has any business poking kernel memory. What if I replace Michael's statement with some specific use cases: - An activity requires a specific device driver module to be (un)loaded to properly function and loading this driver requires su privilege. or: - An activity requires a device to switch operation modes and that operation mode is configured via a sysfs file. The file is poked by a library API, but it requires su privilege to do so. I agree with Paul that we need to have a solution to these cases iff we want to support running arbitrary software and hw combinations on the XO. The other option is to limit the scope of the system to a very specific set of sw and hw, treating the XO as embedded education appliance instead of a general-purpose laptop device, which I don't think we want to do. It can be a general purpose laptop. And we need not surrender our common sense: if we want the thing to be better, it will have to be different. In particular, it cannot have kernel modules promiscuously loaded and unloaded. Thus not all software will run on the laptop. But that is already the case for the most widely distributed home systems: a Microsoft program will not run on GNU/Linux, an Apple program will not run on a Microsoft OS, etc.. I don't have any immediate answers to any of Michael's questions but I think looking at how the standard ditros deal with this would be a starting point. ~Deepak The usual free Unices' security apparatus is ludicrously inadequate. The XO system should be much better. oo--JS. -- Deepak Saxena [EMAIL PROTECTED] ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Security] SuperUser permission for the Driver??
On Thu, 26 Jun 2008, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Deepak Saxena wrote: | I agree with Paul that we need to have a solution to these | cases iff we want to support running arbitrary software and | hw combinations on the XO. The other option is to limit the | scope of the system to a very specific set of sw and hw, | treating the XO as embedded education appliance instead of | a general-purpose laptop device, which I don't think | we want to do. That is _precisely_ what I want to do. OLPC's goal is to distribute XOs to the poorest children in the world. That means that in the category of electronics, the great majority will have the XO and nothing else. Peripherals are a rarity, an edge case. There is a planned design to allow the user to grant extra privileges to different Activities, but those privileges will probably never extend to loading arbitrary kernel modules. I have no problem declaring that anyone who is modifying the kernel is a developer, and should therefore get a devkey and call modprobe themselves. - --Ben Yes. oo--JS. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjw/AACgkQUJT6e6HFtqQlSgCfbDujhumR3cmtT/MpEH8qQidC cYEAn0atipCHDcuYjAIvS/E6IpxD0Ktb =WJse -END PGP SIGNATURE- ___ Security mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/security ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
We have an activity that wants superuser privilege in order to poke kernel memory. The real questions we should be attempting to address here include: * Who is granting privilege to this activity? * How are they doing so? * How should we record the decision? - My tentative answer is that we should store activities with different security properties in well-known directory chains with appropriately restricted write access. * What kinds of abuse are these mechanisms vulnerable to? * Whose responsibility is it to handle the error condition that the human operator does not, him-or-herself posess superuser privilege, e.g. for theft-deterrence reasons? Comments? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
I am new to programming on Linux, I just searched for Setuid() and found that it sets the effective userid of my program to the userid I specify. So can I just call setuid() in my program when I need superuser privileges and have those privileges. To what part of my program are those privileges confined to? Thanks Shivaprasad On Wed, Jun 25, 2008 at 11:23 AM, James Cameron [EMAIL PROTECTED] wrote: So it is root UID you need for a user-space program, not a kernel driver, I see. Have you considered setuid? -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
On 25.06.2008 08:07, Michael Stone wrote: We have an activity that wants superuser privilege in order to poke kernel memory. Hello? Please take the poor activity out back and shoot it. No activity has any business poking kernel memory. The real questions we should be attempting to address here include: * Who is granting privilege to this activity? Everybody who wants to ridicule the security model. * How are they doing so? * How should we record the decision? - My tentative answer is that we should store activities with different security properties in well-known directory chains with appropriately restricted write access. * What kinds of abuse are these mechanisms vulnerable to? * Whose responsibility is it to handle the error condition that the human operator does not, him-or-herself posess superuser privilege, e.g. for theft-deterrence reasons? Just say no. Having an activity poke kernel memory is a really strong sign that the interface is totally broken. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
Sorry for being naive before. Now I have got rules file in udev which grants access for my usb driver to detach the usb device from the kernel and my driver works fine without having to be super user. Thank you so much for all your suggestions. But I got one more question for you, now to install the activity and having it running I have to copy the rules file into /etc/udev/rules.d folder. How can I do this while installing the activity itself. ( I need to make sure that when I unzip my activity .xo file the rules file lands in the /etc/udev/rules.d folder) On Wed, Jun 25, 2008 at 5:31 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: On 25.06.2008 08:07, Michael Stone wrote: We have an activity that wants superuser privilege in order to poke kernel memory. Hello? Please take the poor activity out back and shoot it. No activity has any business poking kernel memory. The real questions we should be attempting to address here include: * Who is granting privilege to this activity? Everybody who wants to ridicule the security model. * How are they doing so? * How should we record the decision? - My tentative answer is that we should store activities with different security properties in well-known directory chains with appropriately restricted write access. * What kinds of abuse are these mechanisms vulnerable to? * Whose responsibility is it to handle the error condition that the human operator does not, him-or-herself posess superuser privilege, e.g. for theft-deterrence reasons? Just say no. Having an activity poke kernel memory is a really strong sign that the interface is totally broken. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
SuperUser permission for the Driver??
Hi, I have USB devices (not storage devices, just some usb devices), which I can use along with my application on the olpc. The driver for these USB devices are third paty drivers so I have to detach the kernel usb driver so that I can use my own driver for that USB device. For this I need to have super user privileges while running my application. I am new to programming on Linux. Could anybody point me as to how I can give superuser privileges to my driver code. Thanks Shivaprasad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
On Jun 24 2008, at 17:35, shivaprasad javali was caught saying: Hi, I have USB devices (not storage devices, just some usb devices), which I can use along with my application on the olpc. The driver for these USB devices are third paty drivers so I have to detach the kernel usb driver so that I can use my own driver for that USB device. For this I need to have super user privileges while running my application. I am new to programming on Linux. Could anybody point me as to how I can give superuser privileges to my driver code. See http://wiki.laptop.org/go/Su I am not completely sure I grok what you need. Are you trying to load a driver via insmod or run some installer for the driver? Note that until two days ago, the USB driver was built into to the kernel, so you can't unload it. What specific device and driver is this? ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
The problem is that when I launch the application from the activity taskbar(the activity icons at the bottom of the screen) It will run under normal user privileges(right??). But for the application to work properly the USB driver has to run under superuser privileges. So I have to figure out how to do this while the application as a whole still has normal user privileges. It all works properly if I go to the terminal su from there and then launch the application from that terminal. Thanks Shivaprasad On Wed, Jun 25, 2008 at 10:07 AM, shivaprasad javali [EMAIL PROTECTED] wrote: The USB HID device which works along with my application needs a third party driver(libhid). So I have to detach the device from the kernel before I starting using my own drivers. So I need superuser permission for that to detach the USB device from the kernel. I call hid_force_open() (this is a libhid() call which detaches the USB device from the kernel and then start using its own driver) Hope this makes it clear as to what I am trying to do. :) Thanks Shivaprasad On Tue, Jun 24, 2008 at 9:29 PM, Deepak Saxena [EMAIL PROTECTED] wrote: On Jun 24 2008, at 17:35, shivaprasad javali was caught saying: Hi, I have USB devices (not storage devices, just some usb devices), which I can use along with my application on the olpc. The driver for these USB devices are third paty drivers so I have to detach the kernel usb driver so that I can use my own driver for that USB device. For this I need to have super user privileges while running my application. I am new to programming on Linux. Could anybody point me as to how I can give superuser privileges to my driver code. See http://wiki.laptop.org/go/Su I am not completely sure I grok what you need. Are you trying to load a driver via insmod or run some installer for the driver? Note that until two days ago, the USB driver was built into to the kernel, so you can't unload it. What specific device and driver is this? ~Deepak -- Deepak Saxena [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: SuperUser permission for the Driver??
So it is root UID you need for a user-space program, not a kernel driver, I see. Have you considered setuid? -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
