TinyLogin

TinyLogin

[Juan C. Villa]

Hey guys,

I deleted my local download cache yesterday and I have not been able to rebuild my distro with OpenEmbedded because the TinyLogin (http://tinylogin.busybox.net/) program got merged into BusyBox. 

recipes/tinylogin/tinylogin_1.4.bb  needs to be updated.

Regards,
-
Juan C. Villa
Computer Engineering
Georgia Institute of Technology
juanqui@gatech.edu
(404)441-9653
From pb@reciva.com Sat Mar 28 22:56:06 2009
Received: from [82.71.203.194] (helo

Re: TinyLogin

[Phil Blundell]

On Sat, 2009-03-28 at 17:15 -0400, Juan C. Villa wrote:
> Hey guys,
> 
> I deleted my local download cache yesterday and I have not been able to rebuild my distro with OpenEmbedded because the TinyLogin (http://tinylogin.busybox.net/) program got merged into BusyBox. 
> 
> recipes/tinylogin/tinylogin_1.4.bb  needs to be updated.

Yes, it seems the crazy busybox dudes have removed the old tinylogin
sources.  That's a bit of a pain.

Are there any mirrors where the files are still available?

p.

Re: TinyLogin

[Denys Dmytriyenko]

On Sat, Mar 28, 2009 at 09:54:06PM +0000, Phil Blundell wrote:
> On Sat, 2009-03-28 at 17:15 -0400, Juan C. Villa wrote:
> > Hey guys,
> > 
> > I deleted my local download cache yesterday and I have not been able to rebuild my distro with OpenEmbedded because the TinyLogin (http://tinylogin.busybox.net/) program got merged into BusyBox. 
> > 
> > recipes/tinylogin/tinylogin_1.4.bb  needs to be updated.

http://thread.gmane.org/gmane.comp.handhelds.openembedded/21701

> Yes, it seems the crazy busybox dudes have removed the old tinylogin
> sources.  That's a bit of a pain.
> 
> Are there any mirrors where the files are still available?

http://www.angstrom-distribution.org/unstable/sources/tinylogin-1.4.tar.bz2

-- 
Denys

Re: TinyLogin

[Phil Blundell]

On Sat, 2009-03-28 at 18:53 -0400, Denys Dmytriyenko wrote:
> http://www.angstrom-distribution.org/unstable/sources/tinylogin-1.4.tar.bz2

Is that URL stable or is it liable to disappear?

p.

Re: TinyLogin

[Koen Kooi]

On 29-03-09 11:00, Phil Blundell wrote:
> On Sat, 2009-03-28 at 18:53 -0400, Denys Dmytriyenko wrote:
>> http://www.angstrom-distribution.org/unstable/sources/tinylogin-1.4.tar.bz2
>
> Is that URL stable or is it liable to disappear?

It will be there at least 3 years from now, GPL obligation and all.

regards,

Koen

Re: TinyLogin

[Holger Schurig]

> recipes/tinylogin/tinylogin_1.4.bb  needs to be updated.

And maybe it should be deprecated as well. With Busybox 1.13.3 
you won't need TinyLogin at all.

Re: TinyLogin

[Koen Kooi]

On 30-03-09 10:53, Holger Schurig wrote:
>> recipes/tinylogin/tinylogin_1.4.bb  needs to be updated.
>
> And maybe it should be deprecated as well. With Busybox 1.13.3
> you won't need TinyLogin at all.

You do if you don't want busybox to run setuid root.

regards,

Koen

Re: TinyLogin

[Holger Schurig]

> > And maybe it should be deprecated as well. With Busybox
> > 1.13.3 you won't need TinyLogin at all.
>
> You do if you don't want busybox to run setuid root.

Is this a problem?  After all, busybox can drop priviledges:

-------------------------------
CONFIG_FEATURE_SUID

With this option you can install the busybox binary belonging to 
root with the suid bit set, and it will automatically drop 
priviledges for applets that don't need root access.
-------------------------------

The text goes further in case you don't trust busybox' auto-drop 
capability:

-------------------------------
If you are really paranoid and don't want to do this, build two 
busybox binaries with different applets in them (and the 
appropriate symlinks pointing to each binary), and only set the 
suid bit on the one that needs it. The applets currently marked 
to need the suid bit are:

crontab, dnsd, findfs, ipcrm, ipcs, login, passwd, ping, su,
traceroute, vlock.
----------------------------------


So, the paranoid thinking would make a tinylogin_1.13_3.bb file, 
which has busybox 1.13.3 in it's SRC_URI, select only the stuff 
needed for passwd, login, su and friends and install that a 
SUID.

In the meantime, I'm happy with my CONFIG_FEATURE_SUID-configured 
busybox :-)

Re: TinyLogin

[Phil Blundell]

On Mon, 2009-03-30 at 10:18 +0100, Holger Schurig wrote:
> Is this a problem?  After all, busybox can drop priviledges:

Indeed it can, and for some distros that might well be a fine solution.
However, for other distros the prospect of a setuid-root busybox is an
unwelcome one, typically for some combination of the following reasons:

- making busybox be setuid means that you need to trust all the applets
to drop privileges that they don't need;

- there's no way of telling, from inspection of the binary, which
applets will run as setuid and which won't, nor of changing the setuid
attribute on individual applets without recompiling;

- security auditing is difficult, since the large amount of code-sharing
in busybox makes it hard to determine which functions can potentially be
called from a setuid context;

- the relatively high rate of code churn, combined with the large amount
of code re-use and the fact that there's no inbuilt guard against
accidentally mixing privilege domains, means that any audit would be
likely to need repeating frequently.

> If you are really paranoid and don't want to do this, build two 
> busybox binaries with different applets in them

That does help with the first two points above, but not with the latter
two.  And, if you're going to build a separate binary for the login
utilities, you might just as well have gone on using tinylogin in the
first place.

p.

Re: TinyLogin

[Michael 'Mickey' Lauer]

Using busybox' tinylogin with the per-applet suid feature has been on my todo 
list for quite a while. I wouldn't mind, if you could do it :)

Since not every one trusts busybox though, we would need to make it 
configurable.

Cheers,

:M:

Re: TinyLogin

[Holger Schurig]

> - security auditing is difficult, since the large amount of
> code-sharing in busybox makes it hard to determine which
> functions can potentially be called from a setuid context;

Can I assume from this that you didn't actually look at busybox's 
source-code?

In libbb/appletlib.c, function "check_suid(int applet_no)":

if (APPLET_SUID(applet_no) == _BB_SUID_ALWAYS) {
        /* Real uid is not 0. If euid isn't 0 too, suid bit
         * is most probably not set on our executable */
        if (geteuid())
                bb_error_msg_and_die("must be suid to work"
                                     "properly");
} else if (APPLET_SUID(applet_no) == _BB_SUID_NEVER) {
        xsetgid(rgid);  /* drop all privileges */
        xsetuid(ruid);
}


The function is called by run_applet_no_and_exit(), which is the 
only way to run an applet. So it's always called.

Maybe you'll also look at include/applets.h, where we have lines 
like:

USE_BRCTL(APPLET(brctl, _BB_DIR_USR_SBIN, _BB_SUID_NEVER))

and then you can check the definition of APPLET_SUID() in 
include/busybox.h


From what I gathered in just a few minutes, this doesn't seem to 
be "hard to determine".

Also I fear that many people that now insist "This is no 
thoroughtly done security examination" --- and which are 
right ---  never actually didn't do a proper security 
examination of tinylogin either.



> - the relatively high rate of code churn, combined with the
> large amount of code re-use and the fact that there's no
> inbuilt guard against accidentally mixing privilege domains,
> means that any audit would be likely to need repeating
> frequently.

This seems to be not true from what the code says. ALL calls to 
busybox applets go via the above quoted function, it's not the 
the case that each applet individually drops it's priviledge --- 
and that therefore it's easy for one applet to forget dropping.


>
> > If you are really paranoid and don't want to do this, build
> > two busybox binaries with different applets in them
>
> That does help with the first two points above, but not with
> the latter two.

> And, if you're going to build a separate binary for the login
> utilities, you might just as well have gone on using tinylogin
> in the first place. 

Except that TinyLogin is end-of-life and won't get bugfixes from 
upstream.

Re: TinyLogin

[Phil Blundell]

On Mon, 2009-03-30 at 11:54 +0100, Holger Schurig wrote:
> > - security auditing is difficult, since the large amount of
> > code-sharing in busybox makes it hard to determine which
> > functions can potentially be called from a setuid context;
> 
> Can I assume from this that you didn't actually look at busybox's 
> source-code?

No, I think you misunderstood what I meant.

The difficulty isn't in determining which applets will run as setuid; as
you say, that's straightforward to determine from the source code
(although not from the binary).  

The issue is that, since all the applets are linked together into one
monolithic binary, and hence have the ability in theory to call any
function in that binary, it is difficult to tell by looking at the
source code which functions might potentially be called (directly or
indirectly) by one of the setuid applets and hence would need to be
included in an audit for privilege-escalation vulnerabilities.

> Except that TinyLogin is end-of-life and won't get bugfixes from 
> upstream.

Yes, that's obviously the tradeoff.  Tinylogin is simple enough, though,
that fixing bugs locally would be easy enough if that became necessary.

p.

Re: TinyLogin

[Holger Schurig]

> No, I think you misunderstood what I meant.

Okay.

> The issue is that, since all the applets are linked together
> into one monolithic binary, and hence have the ability in
> theory to call any function in that binary, it is difficult to
> tell by looking at the source code which functions might
> potentially be called (directly or indirectly) by one of the
> setuid applets and hence would need to be included in an audit
> for privilege-escalation vulnerabilities.

I'd have to cross-ref one specific busybox version with my 
specific .config file and look the call graph below the 
SUID-root applets. That would reveal if this is a substantial 
claim or just a fear.

But hey, I am among those people that didn't do a 
priviledge-escalation-verification of tinylogin. And so I'm not 
inclined to do that now for busybox --- it's not something that 
I care fore.  The usage-scenarios of my devices don't call for 
such measures.

However, I like to base fear on evidence, that's why I replied.


> > Except that TinyLogin is end-of-life and won't get bugfixes
> > from upstream.
>
> Yes, that's obviously the tradeoff.

The end-of-life argument is an argument for my 
paranoid-suggestion ("create a tinylogin_1.13.3_bb file with 
SRC_URI = busybox and a stripped down .config only for the 
tinylogin-equivalent-applets").


> Tinylogin is simple enough, though, that fixing bugs locally
> would be easy enough if that became necessary.

Your point <smile>

Let's wait (some more years) for the security assessment of 
tinylogin then <even bigger smile>.

Re: TinyLogin

[Mike (mwester)]

Holger Schurig wrote:

> However, I like to base fear on evidence, that's why I replied.

Having spent 4 years of my life working in the security space, and a
year of that actually reviewing source code for security-related issues,
I can safely say that in my part of the world (central US), it is the
other way around:

when security is involved, fear is based on _lack_ of evidence of
correctness.

Due to its size and frequency of change the code is impossible for human
review, and due to structure of the code, it is unlikely for automated
commercial tools to be able to do much with it (I know; I tried once).

IMO (for what that's worth), we need to support the "everything is
busybox!" sort of build; there's just no alternative for small devices.
 But the problem is what do we do for that middle ground, for devices
that can't fit the entire set of "proper" tools but might not be willing
to take the security risk associated with running busybox SETUID.

I rather suspect tinylogin will live on, even if maintenance is minimal.

-Mike (mwester)

Re: TinyLogin

[Yuri Bushmelev]

Hello!

> IMO (for what that's worth), we need to support the "everything is
> busybox!" sort of build; there's just no alternative for small devices.
>  But the problem is what do we do for that middle ground, for devices
> that can't fit the entire set of "proper" tools but might not be willing
> to take the security risk associated with running busybox SETUID.

Can we build two busybox'es? One with ordinary non-suid-tools and one with 
all suid? Is it crazy idea? :)

Can someone look here for login replacement (about using on Linux):
http://www.freebsd.org/cgi/cvsweb.cgi/src/release/picobsd/tinyware/login/

and may be here for some other tools:
http://www.freebsd.org/cgi/cvsweb.cgi/src/release/picobsd/tinyware/

-- 
Yuri Bushmelev

Re: TinyLogin

[Phil Blundell]

On Mon, 2009-03-30 at 19:37 +0400, Yuri Bushmelev wrote:
> Can we build two busybox'es? One with ordinary non-suid-tools and one with 
> all suid? Is it crazy idea? :)

I think that's more or less what Holger was suggesting.  It's not a
crazy idea, no, but neither is it a complete panacea.

p.