keys generated on one architecture for another?

[Yan Seiner]

Matt Johnston wrote:
> On Wed, Aug 16, 2006 at 03:41:49AM -0700, Yan Seiner wrote:
>   
>> I finally got around to figuring out what was going on, and I have an 
>> issue that may be a bug/security issue/lack of understanding on my part...
>>     
>
>   
>> -rw-------  1 yan yan 457 2006-04-06 16:14 dropbear_dss_host_key
>> -rw-------  1 yan yan 427 2006-04-06 16:13 dropbear_rsa_host_key
>> And dropbear fails with:
>> open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3
>> read(3, 0x2edf8, 1700)                  = -1 EIO (Input/output error)
>>     
>
>   
>> -rw-------  1 root root 457 2006-04-06 16:14 dropbear_dss_host_key
>> -rw-------  1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key
>> and dropbear fails with:
>> open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3
>> read(3, 0x2edf8, 1700)                  = -1 EACCES (Permission denied)
>>     
>
>   
>> So we change the perms to 644 and dropbear finally succeeds....
>> -rw-r--r--  1 root root 457 2006-04-06 16:14 dropbear_dss_host_key
>> -rw-r--r--  1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key
>> open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3
>> read(3, "\0\0\0\7ssh-rsa\0\0\0\3\1\0\1\0\0\0\203\0\300\234C\260"..., 
>>
>> Now I am really confused.....
>>     
>
> That really looks like there's something wrong at the
> OS/filesystem level? All the manpages I've looked at (Linux,
> Darwin, Tru64, Solaris) don't mention read() returning with
> EACCESS.  I would've expected that to happen in the open()
> call. Even then root should be able to read it unless
> there's some unusual security setup?
>   

The system is running glibc-2.3.2, and busybox 1.2.1.  No unusual setup 
at all; basically a stock compile using a crosstool from kegel.com.  The 
fs is hand-built by moving libs and executables to the target fs, and 
setting permissions as we go.

There are two possibilites I can think of.  One is a bug in busybox's 
nfs.... The target box (an arm board) is mounting the fs via nfs.  The 
second is a missing library.  I've done some spidering through the lib 
dependencies, and I think I have them all, but it is possible I am 
missing one.
> The EIO return should be handled better by Dropbear, though
> I don't think it's the correct return value from the OS (it
> should indicate a physical error)? I'll fix up the error
> checking in Dropbear's buf_readfile() function.
>   
>   
>> I didn't see anywhere in the strace logs that dropbear relinquished su 
>> priveledges, and it is run as root:
>>     
>
> Yep, the main server process runs as root. 
>
> I guess this is a Linux variant from the ps listing. Which
> filesystem is it running? I suspect that's where the problem
> lies.
>   

I suspect there may be some issues between busybox 1.2.1 and my kernel 
as pertains to console handling....  I don't know if that's what I'm 
seeing here.

I have an older, heavily patched version I used for development earlier 
on.  I'll see if I can reproduce the problem with it.

--Yan