Re: dev/console catch 22
On Tue, Jun 19, 2007 at 09:52:27AM -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: So the file hierarchy served by the NFS server must be written by the a host process and I still have the issue of needing elevated privileges to do that for the special console node. i dont really buy this ... only the root user can set up NFS exports and in order for it to be usable by the embedded machine, it has to have root access ... so basically, your system is already insecure so giving away sudo to everyone is exactly the same Maybe you could run the user-space NFS server inside fakeroot? ;) I have not tried this. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tuesday 19 June 2007, Hamish Moffatt wrote: On Tue, Jun 19, 2007 at 09:52:27AM -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: So the file hierarchy served by the NFS server must be written by the a host process and I still have the issue of needing elevated privileges to do that for the special console node. i dont really buy this ... only the root user can set up NFS exports and in order for it to be usable by the embedded machine, it has to have root access ... so basically, your system is already insecure so giving away sudo to everyone is exactly the same Maybe you could run the user-space NFS server inside fakeroot? ;) fakeroot only stops dynamic applications ... it does not work on static -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Monday 18 June 2007, Mike Cashwell wrote: No, as discussed, that just trades a problem on the target (no console) for one on the host (habituating the use of elevated privileges). then you're not creating your images correctly ... any sane filesystem image utility allows for device creation and for squashing of permissions in the target image -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tue, 2007-06-19 at 03:00 -0400, Mike Frysinger wrote: On Monday 18 June 2007, Mike Cashwell wrote: No, as discussed, that just trades a problem on the target (no console) for one on the host (habituating the use of elevated privileges). then you're not creating your images correctly ... any sane filesystem image utility allows for device creation and for squashing of permissions in the target image OK, I've seen some threads (here and elsewhere) about doing this. That may help with the stand-alone root image but that only covers part of the workflow we use. During development we net-boot the targets using an NFS root mount. Once a dev cycle stabilizes and we want to take the devices off the LAN we flash an image into them. (In the past this has been cramfs but I'm considering squashfs.) So the file hierarchy served by the NFS server must be written by the a host process and I still have the issue of needing elevated privileges to do that for the special console node. The odd part is that all this worked under the 2.4.20 kernel and an earlier version of Busybox. My hunch is that the now-deprecated devfs was handling the console node for me without me even knowing it. Under the new sysfs / mdev we must get further into init before the console works. That's all just supposition on my part but it's the largest different from what used to work that I can see. -Mike ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Mon, 2007-06-18 at 18:31 -0400, Michael Cashwell wrote: Basically, I'm finding that if I don't have the special character file in /dev (made via sudo mknod dev/console c 5 1) that I can't get a serial console to work on my target device. This is a real pain in terms of our developers' workflow. Everything else can be done without habituating the use of sudo (including building the target's kernel) so it seems odd indeed that it's needed for this one dev node. Sorry about replying to myself here, but in the interests of adding potentially useful data to the archives I've found an acceptable solution to my dilemma. The solution also leads to a possible clarification or update to the Busybox inittab documentation. My solution avoids the need for any special device nodes in the target file system (be it in FLASH or via NFS). Lacking that node the kernel does complain that it can't create an initial console and indeed console output during my init script is lost, but I can live with that. My solution was to note in inittab's documentation that sysinit is synchronous (eg: each completes in order before any other inittab line is executed). That made be realize that my ::sysinit:/etc/rc would have created the needed console dev node (in a /dev tmpfs mount) by the time anything else happened. My confusion was in thinking that init itself had to have that node open as the console in order to log in. That proved to not be the case. The key insight was that the next inittab line needed to be console::askfirst:-/bin/ash. Without the console it wouldn't work. I did not expect this since the documentation (downloads/BusyBox.html in the example inittab section) says that ::askfirst:-/bin/ash (which is what I had) starts an askfirst shell on the console (whatever that may be). I interpreted this to mean that a missing ID was replaced with console but that otherwise the behavior of the two cases would be identical. They are not. Without an explicit ID, init seems to use whatever FD 0 it inherited from the kernel. While conceptually that is the console, it's pretty different behavior from the explicit case where init actually opens a path /dev/id and gets a new FD. Anyway, thanks for the assistance. -Mike ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tuesday 19 June 2007, Michael Cashwell wrote: My solution was to note in inittab's documentation that sysinit is synchronous (eg: each completes in order before any other inittab line is executed). That made be realize that my ::sysinit:/etc/rc would have created the needed console dev node (in a /dev tmpfs mount) by the time anything else happened. will do My confusion was in thinking that init itself had to have that node open as the console in order to log in. That proved to not be the case. sorry, i thought you wanted everything to be outputting to the console, not just the login shell The key insight was that the next inittab line needed to be console::askfirst:-/bin/ash. Without the console it wouldn't work. I did not expect this since the documentation (downloads/BusyBox.html in the example inittab section) says that ::askfirst:-/bin/ash (which is what I had) starts an askfirst shell on the console (whatever that may be). might be worthwhile to change the default as well so it opens console I interpreted this to mean that a missing ID was replaced with console but that otherwise the behavior of the two cases would be identical. They are not. Without an explicit ID, init seems to use whatever FD 0 it inherited from the kernel. While conceptually that is the console, it's pretty different behavior from the explicit case where init actually opens a path /dev/id and gets a new FD. correct -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On 6/19/07, Mike Cashwell [EMAIL PROTECTED] wrote: create the device node in the image, problem solved No, as discussed, that just trades a problem on the target (no console) for one on the host (habituating the use of elevated privileges). I understand some security concern for the host system in creating these nodes but my frustration is that I'm not targeting the host system. I'm doing it for the target. And I can write every file the target needs (including its kernel!) as a normal user except for this one special file. Is it expected that creating a bootable file system (with a working console) requires the use of elevated privileges? No. It happens because you create image by loop-mounting it. Possible solutions: * Have prepared empty image with pre-created /dev/cosole, and loop-mount that. (Going to be tiny in bz2) * Find or write tools which can manipulate ext2 (or other fs) image directly * Use UML. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tue, 2007-06-19 at 09:52 -0400, Mike Frysinger wrote:
On Tuesday 19 June 2007, Michael Cashwell wrote:
So the file hierarchy served by the NFS server must be written by the a
host process and I still have the issue of needing elevated privileges
to do that for the special console node.
i dont really buy this ... only the root user can set up NFS exports and in
order for it to be usable by the embedded machine, it has to have root
access
I disagree. The NFS setup is only done once per NFS server. So while the
exported space is insecure and it took elevated privileges to create,
it's just developmental scratch space and has no security implication on
other hosts.
... so basically, your system is already insecure so giving away sudo
to everyone is exactly the same
I don't know what system you are talking about here. The insecure NFS
export is on a machine dedicated to that task. And besides, denying the
developers sudo access was never my goal. (They need it for quite a few
other reasons anyway.) Heck, I'm one of those developers too!
My goal is to avoid habituating the use of sudo in our normal workflow.
The reason is that it's dangerous when something goes wrong. I've
mandated that when cross-compiling there is to be no need for the power
of sudo make install. That one rule has saved me on several occasions
when something was wrong in the build process and it went off trying to
install into the host's protected areas (/etc, /lib, /bin). A sane
cross-build process that avoids the needless use of elevated privileges
protects against those mishaps.
My goal was to either find a way to create the target console node
without elevated host privileges or to avoid needing the device node in
the first place.
The odd part is that all this worked under the 2.4.20 kernel and an
earlier version of Busybox. My hunch is that the now-deprecated devfs
was handling the console node for me without me even knowing it.
correct
It's nice to understand what changed.
Under
the new sysfs / mdev we must get further into init before the console
works. That's all just supposition on my part but it's the largest
different from what used to work that I can see.
not really, /dev is assumed to at least have /dev/console before userspace
even starts ... if it doesnt, you're right back where i said and that's
patching init to open /dev/console and re-exec itself
Yes, for the strict interpretation of console this seems to be true. But
as noted in a later email it's a small window of lost console output.
you could also do init=/sbin/pre_init which is a small piece of code that
simply creates /dev/console and then opens it up for std{in,out,err} before
doing execv(/sbin/init)
I've essentially done this by using a systinit script to create the
device node and then do an askfirst /bin/ash (or /bin/login) to then use
that node to get a shell on the target over the serial port. init never
has a console but I can live with that.
I am left wondering if there isn't some way to get init to actually
reexec itself without patching it. It seems that the inittab restart
would do that if I could get init to exit. But given my inittab success
I have back the main functionality I needed so further exploration will
have to wait.
Thanks for the input.
-Mike
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tuesday 19 June 2007, Michael Cashwell wrote: On Tue, 2007-06-19 at 09:52 -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: So the file hierarchy served by the NFS server must be written by the a host process and I still have the issue of needing elevated privileges to do that for the special console node. i dont really buy this ... only the root user can set up NFS exports and in order for it to be usable by the embedded machine, it has to have root access I disagree. The NFS setup is only done once per NFS server. So while the exported space is insecure and it took elevated privileges to create, it's just developmental scratch space and has no security implication on other hosts. sure it does ... the embedded machine is mounting the server as root and you have full access to the embedded machine ... what's stopping you from creating a .c program that simply executes /bin/sh, sending it to the board, the board sending it to the nfs server, and then giving it setuid perms ? cheap root shell hello I am left wondering if there isn't some way to get init to actually reexec itself without patching it. It seems that the inittab restart would do that if I could get init to exit. But given my inittab success I have back the main functionality I needed so further exploration will have to wait. might be something to look into, but personally i just dont think this has relevance in any sort of actual deployed production system -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tue, 2007-06-19 at 11:48 -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: On Tue, 2007-06-19 at 09:52 -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: So the file hierarchy served by the NFS server must be written by the a host process and I still have the issue of needing elevated privileges to do that for the special console node. i dont really buy this ... only the root user can set up NFS exports and in order for it to be usable by the embedded machine, it has to have root access I disagree. The NFS setup is only done once per NFS server. So while the exported space is insecure and it took elevated privileges to create, it's just developmental scratch space and has no security implication on other hosts. sure it does ... the embedded machine is mounting the server as root No it isn't. The NFS space is offered read-only and no_root_squash to the target devices. Root access on the targets is thus non-root on the NFS box. Could that be defeated given that other hosts have write access? Sure, but... and you have full access to the embedded machine ... The same set of users has sudo on the NFS server and development machines too. (So I should have said there's no _additional_ security implication.) But trying to implement a secure, NFS-based netboot setup was not my goal. The developers are trusted users. My goal was to avoid habitual sudo on the development machines for the daily workflow. The purpose is to avoid accidental damage to those machines by having sudo used rarely and with deliberation. what's stopping you from creating a .c program that simply executes /bin/sh, sending it to the board, the board sending it to the nfs server, and then giving it setuid perms ? cheap root shell hello Doesn't seem very cheap to me. It seems quite laborious when compared to just using sudo directly. I am left wondering if there isn't some way to get init to actually reexec itself without patching it. It seems that the inittab restart would do that if I could get init to exit. But given my inittab success I have back the main functionality I needed so further exploration will have to wait. might be something to look into, but personally i just dont think this has relevance in any sort of actual deployed production system Quite so. I think it only matters when the kernel can't open the console. -Mike ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tuesday 19 June 2007, Michael Cashwell wrote: On Tue, 2007-06-19 at 11:48 -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: I am left wondering if there isn't some way to get init to actually reexec itself without patching it. It seems that the inittab restart would do that if I could get init to exit. But given my inittab success I have back the main functionality I needed so further exploration will have to wait. might be something to look into, but personally i just dont think this has relevance in any sort of actual deployed production system Quite so. I think it only matters when the kernel can't open the console. which is really only an issue for development right ? the proper production image will have /dev/console in place already ... -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: dev/console catch 22
On Tue, 2007-06-19 at 13:45 -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: On Tue, 2007-06-19 at 11:48 -0400, Mike Frysinger wrote: On Tuesday 19 June 2007, Michael Cashwell wrote: I am left wondering if there isn't some way to get init to actually reexec itself without patching it. It seems that the inittab restart would do that if I could get init to exit. But given my inittab success I have back the main functionality I needed so further exploration will have to wait. might be something to look into, but personally i just dont think this has relevance in any sort of actual deployed production system Quite so. I think it only matters when the kernel can't open the console. which is really only an issue for development right ? the proper production image will have /dev/console in place already ... Hmm. Yes, that's a fair point too. Production devices will boot only from FLASH and as noted there are ways to create the special file in such file systems. I hadn't done so in the past because under 2.4 with devfs it wasn't needed. But I will address that now. -Mike ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
dev/console catch 22
I have a question about how to create my target's initial file system. Basically, I'm finding that if I don't have the special character file in /dev (made via sudo mknod dev/console c 5 1) that I can't get a serial console to work on my target device. This is a real pain in terms of our developers' workflow. Everything else can be done without habituating the use of sudo (including building the target's kernel) so it seems odd indeed that it's needed for this one dev node. I don't like making the use of sudo routine. I'm going to get a lot of static from my boss if I say, Oh you have to build the target file system with sudo on the build machine. The target already mounts a tmpfs file system over its /dev and then does the mknod /dev/console c 5 1 magic early in /etc/rc but it seems to not be early enough. Is there some way to have init exit and rerun itself after it's done those steps? Anyone have any other ideas? Any advice would be appreciated. -Mike ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
