dev/console catch 22

[Michael Cashwell]

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