pppd and setuid

[Steve Modica]

I would like to use pppd to create a connection to a generic android device.

I'd like the user to be able to enabled USB debugging, connect to my platform, and then use adb ppp to connect.

From what I can tell, the default android kernel supports this. (CONFIG_PPP and the tty has ppp support).

The problem is that pppd is not setuid. So it cannot open /dev/tty. That makes pppd pretty useless unless the phone is rooted.

Can I create an apk to install a setuid pppd?

Regards
Steve

--
Steve Modica
CTO - Small Tree Communications
www.small-tree.com

[Chris Stratton]

On Monday, August 22, 2011 5:23:33 PM UTC-4, Steve Modica wrote:

I would like to use pppd to create a connection to a generic android device.

I'd like the user to be able to enabled USB debugging, connect to my platform, and then use adb ppp to connect.  

From what I can tell, the default android kernel supports this. (CONFIG_PPP and the tty has ppp support).

The problem is that pppd is not setuid.  So it cannot open /dev/tty.  That makes pppd pretty useless unless the phone is rooted.

Can I create an apk to install a setuid pppd?

No, you can't.  The partitions an apk can write to are mounted with the setuid bit disabled.  These are things you need to incorporate in a custom build of android - the proper way is likely to have device file created with an appropriate unix-level group to control access - possibly a custom one.

A "generic android device" doesn't have a tty suitable for connecting to an external device anyway.  Sometimes there's a debug serial port in the hardware, but you would need platform customizations or a non-secured (or broken-into) build in order to access it.

[Steve Modica]

As a test, I rooted my Xoom and made /system/bin/pppd setuid.  I put su on there as well.

Afterwards, I flashed boot back to factory and was still able to ppp connect with the setuid pppd.  Not sure if that's a left over.  su no longer worked.

The android side is certainly opening /dev/tty OK.  I can post screen shots.  

I like the group access idea. We'll look at that.  I swear I saw apps installing that said something like "this app requires superuser access" (perhaps sshdroid).  What are those doing?

adb ppp "shell:pppd nodetach noauth noipdefault /dev/tty" nodetach noauth noipdefault notty <local-ip>:<remote-ip>

[Chris Stratton]

On Tuesday, August 23, 2011 9:56:59 AM UTC-4, Steve Modica wrote:

I swear I saw apps installing that said something like "this app requires superuser access" (perhaps sshdroid).  What are those doing?

They are leveraging a common aftermarket modification of Android, specifically the addition of some sort of "su" tool willing to run for application user id's. 

[Steve Modica]

Would a more acceptable solution for the generic case be to use port forwarding and non-root apps that just access that port? 

In that way, we could create simple apps to access our embedded device router and not require setuid.

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

[Chris Stratton]

On Wednesday, August 24, 2011 9:55:55 AM UTC-4, Steve Modica wrote:

Would a more acceptable solution for the generic case be to use port forwarding and non-root apps that just access that port? 

In that way, we could create simple apps to access our embedded device router and not require setuid.

Depends on what you are doing.  Are you making a custom version of android? 

If not, it's not clear how you can open any of this up, other than hope that the device is rooted (and in the common way you expect).

If you are making a custom version of android, having a service that listens on a tcp port (to keep things local, on the loopback interface _only_ or instead use a unix domain socket) would be one way to expose things, but it would not really offer much security in making it available to only some applications - it would differ from chmod'ing the device file itself to be world readable & writeable only in that your code would sit there arbitrating and mediating use of the device.

To restrict access to only some apps, you'd need to add a unix group (to own the device file) and android permission (to assign membership in the group) to the android platform. 

Or you can keep the device file owned by a group only available to a java-style android service you package with the system, and have it check that a 3rd-party client app on the other end of the Binder IPC trying to use the service holds a desired android permission or otherwise qualifies as allowed.

This probably belongs on android-porting rather than android-kernel

[Steve Modica]

On Aug 24, 2011, at 11:18 AM, Chris Stratton wrote:

On Wednesday, August 24, 2011 9:55:55 AM UTC-4, Steve Modica wrote:

Would a more acceptable solution for the generic case be to use port forwarding and non-root apps that just access that port? 

In that way, we could create simple apps to access our embedded device router and not require setuid.

Depends on what you are doing.  Are you making a custom version of android? 

If not, it's not clear how you can open any of this up, other than hope that the device is rooted (and in the common way you expect).

If it is, having a service that listens on a tcp port (on the loopback interface _only_ or instead unix domain socket) would be one way to expose things, but it would not really offer much security in making it available to only some applications - it would differ from chmod'ing the device file only in that your code would sit there arbitrating use of the device.

To restrict access to only some apps, you'd need to add a unix group (to own the device file) and android permission (to assign membership in the group) to the android platform. 

Or you can keep the device file owned by a group only available to a java-style android service you package with the system, and have it check that a 3rd-party client app trying to use the service holds a desired android permission or otherwise qualifies as allowed.

I only need one app to work.  So a custom app is fine.  That might be the way then.  

I basically want to take an off the shelf phone, enable USB debugging, install an apk and have it be able to bring up a moving map application (receiving GPS data from our embedded device).  The phone will be operating in a place with no 3G or wifi signals.

This probably belongs on android-porting rather than android-kernel

I'll take it over there now :)

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

--

Steve Modica

CTO -  Small Tree Communications

www.small-tree.com

phone: 651-209-6509 ext 301

mobile: 651-261-3201

[Steve Modica]

I've been looking at adb ppp and I think Android has a bug.

pppd is root:shell.

/dev/tty is root:root

The default user is shell:shell

So it looks to me like /dev/tty *should* be root:shell and then adb ppp would work to an unrooted android device. (with USB debugging enabled)

Why does /dev/tty need to be group "root"?

(/dev/tty works for ppp as well although the Nexus S kernel was unique in not supporting ppp mode on the tty.  The Xoom works fine)

Steve

--
unsubscribe: android-kerne...@googlegroups.com
website: http://groups.google.com/group/android-kernel

--

Steve Modica

CTO -  Small Tree Communications

www.small-tree.com

[Chris Stratton]

On Friday, August 26, 2011 12:55:40 PM UTC-4, Steve Modica wrote:

/dev/tty is root:root

The default user is shell:shell

/dev/tty is assigned mode 666 in both AOSP versions that I checked and on my device.
So it should be rw for any user including both 'shell' and application UID's.

Your difficulty likely lies elsewhere.