Ad Blocking via dnsmasq? - Droid Eris Q&A, Help & Troubleshooting

I've been tinkering with dnsmasq and ad blocking (using the terminal to input commands). It works so far, except breaks the words-with-friends app.
I was thinking that it would be easier to maintain than a HOSTS file (cause you can block subdomains), and that it would be quicker (less resources than the linear lookup of a giant hosts file). I could be completely wrong, but let me know what you think.
To get it running, I do this, more or less:
su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
cp /sdcard/adblock.conf /system/etc/adblock.conf
dnsmasq -C /system/etc/adblock.conf
Then cycle the airplane mode, that sometimes gets it working. If not:
getprop
setprop net.dns1 127.0.0.1
Sometimes it doesn't stick. I had some questions for people that know more than I do:
1. Is it possible to get a pixelserv script running? One of my goals is to block words with friends ads, without breaking words with friends, and I think that might do the trick. (http://proxytunnel.sourceforge.net/pixelserv.php)
2. Would this affect the use of dnsmasq elsewhere, like tethering? Can two dnsmasq instances run at the same time in that case, or would this one have to be ended?
3. Is this a worthwhile endeavor?
PS: The script uses OpenDNS for actual DNS requests. Also, 50-60 ad servers are blocked, they're routed to 0.0.0.0 for speed (as they immediately return invalid, rather than trying to connect), if we were to use the pixelserv in the future, they'd have to go back to 127.0.0.1 for that to work.
PPS: Pixelserv is a perl script, I guess wouldn't run natively, but these may be worth looking at: http://code.google.com/p/android-scripting/ , http://code.google.com/p/perldroid/
Thanks for looking! If this is in the wrong area, please move it.

Another thought, could iptables be used instead? I'm not very familiar with linux

Related

Stealthy free USB Tether technique using IPTABLES

Ok, let me start by saying this Photon has a LOT of potential... Anyways, a little tinkering and hacking and I noticed a few interesting little tidbits.
First, the easy to use Phone Portal feature look rather interesting. Pretty interesting how we can just automagically surf a web page put out by the phone... Oh wait, that would require DHCP and a USBnet Modem wouldn't it?
Kinda. It does use a Motorola Network driver to mimick something similar to the linux usbnet drivers. So as long as you have your Motorola drivers installed on the PC, it'll still launch this portal.
Now I already knew that iptables was installed. So the question now is can this interface be NAT'ed to allow internet access through the phone without installing any software?
The answer, yes.
First root the phone and then when you're logged in you'll want to do the following:
Code:
mount -o remount,rw /dev/block/mmcblk0p12 /system
echo 1 > /proc/sys/net/ipv4/ip_forward [I]#Temporarily allow packet forwarding[/I]
[I]# Permanently allow packet forwarding[/I]
vi /etc/sysctl.conf
[I]# uncomment the line #net.ipv4.ip_forward=1[/I]
vi /etc/rc.local
[I]# Add the following lines after the line that reads iptables -A OUTPUT -p tcp --dport 8085 -d localhost -m owner ! --uid-owner adas -j REJECT[/I]
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -i ppp0 -o usb0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i usb0 -o ppp0 -j ACCEPT
mount -o remount,ro /dev/block/mmcblk0p12 /system
Note: You may need to set the default route of 192.168.16.2 on your computer. You'll also want to set your DNS servers to 4.4.4.4 and 8.8.8.8 (Google) so that you can do DNS queries.
DHCP config coming soon once I figure it out.
Once this modification is done, all you need to do is have your phone in the Motorola Phone Portal Mode and plug it into your computer. Your computer will automatically recognize the network connection, utilize DHCP, and establish an internet connection.
Hoozah, USB tethering with no apps, no fuss, and ... no $30 a month.
Good post, now I wonder if we can get this working with Ubuntu. I don't have the ability to try yet. But I may later tonight.
Thanks for the heads up.
These are shell commands, its not as simple as you'd think to build an aol to do this. And I would guess it only has to be done once unless the phone resets this stuff on reboot...
Sent from my MB855 using xda premium
Yep, only needs to be done once. That's why I put the "temporarily changes" and the "permanently changes" in there.
A note though, local.rc does get updated during patches, so if you take an OTA upgrade, you'll need to redo these steps to get it working again. No more or less so than you would if you needed to recover root.
One of the reasons I posted this here... that way it's documented and if I forget in the future, I can search this site to learn how it's done again.
khawk said:
Ok, let me start by saying this Photon has a LOT of potential... Anyways, a little tinkering and hacking and I noticed a few interesting little tidbits.
First, the easy to use Phone Portal feature look rather interesting. Pretty interesting how we can just automagically surf a web page put out by the phone... Oh wait, that would require DHCP and a USBnet Modem wouldn't it?
Kinda. It does use a Motorola Network driver to mimick something similar to the linux usbnet drivers. So as long as you have your Motorola drivers installed on the PC, it'll still launch this portal.
Now I already knew that iptables was installed. So the question now is can this interface be NAT'ed to allow internet access through the phone without installing any software?
The answer, yes.
First root the phone and then when you're logged in you'll want to do the following:
Code:
mount -o remount,rw /dev/block/mmcblk0p12 /system
echo 1 > /proc/sys/net/ipv4/ip_forward [I]#Temporarily allow packet forwarding[/I]
[I]# Permanently allow packet forwarding[/I]
vi /etc/sysctl.conf
[I]# uncomment the line #net.ipv4.ip_forward=1[/I]
vi /etc/rc.local
[I]# Add the following lines after the line that reads iptables -A OUTPUT -p tcp --dport 8085 -d localhost -m owner ! --uid-owner adas -j REJECT[/I]
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -i ppp0 -o usb0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i usb0 -o ppp0 -j ACCEPT
mount -o remount,ro /dev/block/mmcblk0p12 /system
Note: You may need to set the default route of 192.168.16.2 on your computer.
Once this modification is done, all you need to do is have your phone in the Motorola Phone Portal Mode and plug it into your computer. Your computer will automatically recognize the network connection, utilize DHCP, and establish an internet connection.
Hoozah, USB tethering with no apps, no fuss, and ... no $30 a month.
Click to expand...
Click to collapse
Hi,
I tried everything you've said and can't seem to get an internet connection via tether. First of all, what exactly do you mean, "Note: You may need to set the default route of 192.168.16.2 on your computer"? Do you mean in the IPv4 settings for the Motorola USB Modem on the laptop, to set the Default Gateway and DNS to 192.168.16.2? If so, I've tried this, and still can't see to get an internet connection.
What happens is it tries to load a page, then comes back with an error that it cannot resolve a DNS. Has anyone else had success with this? I'm pretty sure I've edited the files exactly as he's suggested here...
BallCity said:
Hi,
I tried everything you've said and can't seem to get an internet connection via tether. First of all, what exactly do you mean, "Note: You may need to set the default route of 192.168.16.2 on your computer"? Do you mean in the IPv4 settings for the Motorola USB Modem on the laptop, to set the Default Gateway and DNS to 192.168.16.2? If so, I've tried this, and still can't see to get an internet connection.
What happens is it tries to load a page, then comes back with an error that it cannot resolve a DNS. Has anyone else had success with this? I'm pretty sure I've edited the files exactly as he's suggested here...
Click to expand...
Click to collapse
I revised the original post to include DNS config. Opps, overlooked that one.
Can you please specifically show which settings to change in Windows 7 to change the default route and DNS servers? I THINK I've changed the settings in the correct place but my computer does not get an internet connection.
gollyzila said:
Can you please specifically show which settings to change in Windows 7 to change the default route and DNS servers? I THINK I've changed the settings in the correct place but my computer does not get an internet connection.
Click to expand...
Click to collapse
Something as follows:
* Put the phone into Motorola Phone Portal mode [After making the edits outlined above]
* Goto: Control Panel\Network and Internet\Network Connections
* Right-Click and Click Properties on Motorola USB Networking Driver (With a name something like Local Area Connection ##)
* Click on "Internet Protocol Version 4 (TCP/IPv4) and then click the 'Properties' Button
* Set it up to look like this:
h_ttp://i.imgur.com/8w1S0.png
[Won't let me post outside links, so you can figure out how to make that work.]
All done!
I've gotten it working now. I think the issue I had before was with the edits I made. Initially I tried editing the files using Root Explorer's built-in text editor. Since then I've just used ADB to pull them to my computer to edit, then push the edited files over to the SD card via ADB, then moved them to the /etc/ folder with Root Explorer.
Hope that helps someone... But to confirm, I've gotten it working using those edits that the OP had posted, and used the IPv4 settings posted above.
No comment yet on speed or anything. It does appear as though 4G stays connected, though.
Can anyone confirm this still works with the 2.3.4-4.5.1A-1_SUN-198_6-CM SBF? Windows 7 sees the connection but there is no internet access. Are the mount commands required or can I just make the edits to the files (root explorer) and reboot the phone?
Mahna Mahna said:
Can anyone confirm this still works with the 2.3.4-4.5.1A-1_SUN-198_6-CM SBF? Windows 7 sees the connection but there is no internet access. Are the mount commands required or can I just make the edits to the files (root explorer) and reboot the phone?
Click to expand...
Click to collapse
It doesn't seem to work for me on this update, either. Same issue, W7 sees the connection but I also don't get internet access. Using Google's DNS as well. I'm not sure what changed... Anyone else try this and/or know of a fix?
BallCity said:
It doesn't seem to work for me on this update, either. Same issue, W7 sees the connection but I also don't get internet access. Using Google's DNS as well. I'm not sure what changed... Anyone else try this and/or know of a fix?
Click to expand...
Click to collapse
Seems that they did something in the firmware to disable the packet forwarding. I haven't had a lot of time to check this more closely. Would be interesting to see what the differences in the kernel config are between this build and the previous one.

[howto]make hostnames work on busybox

Rooted PDAs only! Shell required!
Before doing the following steps, verify that you don't have an "/etc/resolv.conf"! I reckon none of the stock ROMs have one, but this tweak doesn't work with such a file in place.
Code:
ls -l /etc/resolv.conf || echo "ok"
If this prints some file details and you can use eg. "ping -c 3 www.google.com", you don't have the problem in the first place.
If it says "no such file..." and "ok", go ahead.
Make a file named "/mnt/sdcard/resolv.conf" containing, for example:
Code:
nameserver 8.8.8.8
nameserver 8.8.4.4
These are the IP numbers of the Google public DNS resolvers, BTW, but you can use any others.
Code:
mount -o remount,rw /system &&
ln -s /mnt/sdcard/resolv.conf /etc/
mount -o remount,ro /system
The problem: busybox and other C-programs use a library component called the "stub-resolver" to make IP-adresses from hostnames. This isn't capable of resolving by itself, so it parses "/etc/resolv.conf". The "nameserver" lines in there tell it where to send the UDP packets with questions like "what's the IP of Gmail.com?".
Java programs do this differently: they use "getprop" for the IPs of the nameservers, and vendor customized "dhcpcd" scripts populate the needed properties.
C-programs need the etc/resolv.conf for proper operation.
Q: what does this do for me?
A: first, it'll make symbolic hostnames work for C-programs like "wget", "ping", "nslookup" etc. As added benefit, you can see the names requested by Android programs if you give the IPs of some DNS-resolver you might have in a home LAN. Look at its logs!
Q: what are these '&&' combinations for?
A: well, we don't get to see them often, not even in developer scripts, but they are very useful! They logically "AND" commands. If the command or program before an '&&' fails, none of the following ones will get executed. So if the first "mount" doesn't work (a typo or whatever), the symbolic link by the "ln -s ..." won't be attempted at all, meaning less errors. POSIX requires compliant shells to do this type of short-circuit evaluation, so we can rely on it.
Q: why use a symlink ("ln -s ...") instead of a file?
A: This way you can change nameservers without remounting /system, in fact, you don't even need to be root for this. Change /sdcard/resolv.conf and you're set.
Q: which nameservers should I use?
A: with a patch to "/system/etc/dhcpcd/dhcpcd-hooks/20-dns.conf" it's possible to use the ones from your ISP provided DHCP lease. I thought a onetime manual configuration would do for the moment. You could search the web for the OpenDNS resolvers as an alternative, or use your providers resolvers (eg. from the APN config).
Although I already had resolv.conf added, your explanation for why it is needed was very informative!!! Thanks.
ino-xda said:
Make a file named "/mnt/sdcard/resolv.conf" containing, for example: ...
Click to expand...
Click to collapse
Q: will this work in etc/init.d/ scripts?
A: that depends on when they run. The symbolic link points to a file on the sdcard, thus it will work no sooner than the sdcard has been mounted, but before scanning for media files, icons etc. has finished. Once the device is fully up and running, it should work reliably.

BusyBox Issues

I've been a "rooter" for years now. Had 3 HTC Ones, all rooted and one S-Off. Never had an issue like this. I can seem to get BusyBox to install. When I do get it to install it eventually uninstalls itself for some odd reason. Any suggestions?
What I had to do, is flash busybox from TWRP, installing from playstore did not work at all. It has something to do with HTC security.
I just tried that and couldn't seem to find where it's stored.
Sent from my HTC One using XDA Premium 4 mobile app
Added a couple edits, explained at the end of some paragraphs in case someone comes across this, don't like leaving things incorrect if I know it. I strongly recommend enabling xtrace in the shell to check what's actually being executed, you see your functions and aliases expanded too. With all (busybox ash)|mksh|bash|zsh you can do 'set -x' at any time, append it when calling the shell: 'sh -x' or 'sh -o xtrace' with 'sh' being a symlink to any of the mentioned shells; sh runs the shell in posix mode.
Diesel321 said:
I've been a "rooter" for years now. Had 3 HTC Ones, all rooted and one S-Off. Never had an issue like this. I can seem to get BusyBox to install. When I do get it to install it eventually uninstalls itself for some odd reason. Any suggestions?
Click to expand...
Click to collapse
This sounds like SELinux shenanigans. I don't have the HTC One, but I've experienced similar oddities with a SELinux enforced system. (latest TWRP includes SELinux which might be why a twrp doesn't make a difference) With the addition of the SELinux filesystem, a new "file context" permission is attributable to each file/process. The context defines a user, basic function, that it's in the right place, and a sensitivity parameter. There's some good basic info on the SELinux wiki page with commands.
If your system is using enforced SELinux, a program like busybox installed without setting context is going to be denied to exist/run by default, but this depends on how SELinux is configured. I'm guessing it's context is not being set, so it's getting purged on reboot. Another possible SELinux related issue : a custom kernel that doesn't support SELinux is installed on a rom with SELinux --> bad mix, so if that's the case don't be surprised if more issues like this crop up or a data wipe in your sleep randomly occurs out of nowhere --This happened to me twice actually after disregarding this warning-- You can check your SELinux status with
Code:
getenforce
-in adb or terminal emu. This should also be displayed in phone info menu in settings. Make sure it's "permissive" or "enforced". Permissive logs warnings of what SELinux would do if enforced. You can change SELinux to permissive with:
Code:
setenforce 0
This only works if both your kernel and rom are Selinux compatible. Btw you'll probably find all your SELinux command tools in /system/bin symlinked from toolbox. There's also runcon (run with a context), chcon(change context), restorecon (restore original context), and updates have started integrating a flag (usually -Z) to **filter in** SELinux permissions, e.g. toolbox ls -Z. Busybox does not seem to have updated its tools that could support this, at least on Android. *Even Vanirs busybox 1.22.1.awesome doesn't have the ls -Z function. I was shocked to find out "Toolbox!" was actually useful for something, had a mental breakdown over it a couple months ago. [edit: After reading up on some busybox technical stuff, I found that busybox in its rarely seen full version can in fact be compiled with SELinux extended functions. The reason that almost every rom dev out there uses a busybox that doesn't include every function is portability, case rom to rom ;; older to newer vice versa ;& so that problems will be minimized ;; esac.
**(filters not a good way to put it at 2nd glance, sounds confusing. I mean 'test' or read ACLs<extended perms)
So I would check busybox' context after installing it:
Code:
ls -Z "$(which busybox)"
If it's undefined or unconfined, we will change it to this:
Code:
u:object_r:busybox_exec:s0
.. We can fix it ourselves over adb or in a su'd mksh/bash shell, (use supersu since cwm superuser does not pass arguments correctly or at all in most situations):
Code:
su --shell mksh exec -c mksh -x --
First try to restore original context from file_contexts and see if it works:
Code:
restorecon "$(which busybox)"
Then set busybox' context:
Code:
sync && mount -w -o remount -t ext4 /system /system
chcon u:object_r:busybox_exec:s0 "$(which busybox)"
sync && mount -r -o remount -t ext4 /system /system
*** added "-t ext4" to mount command- it should then work with toolbox or busybox no errors
The other thing I might guess besides all this SELinux file context stuff is that the installation of the busybox binary didn't write to disk. If you run fsync off in your kernel, a fast reboot soon after busybox installation could very possibly lead to data loss of recent files. Similarly, but without a huge risk of collateral damage, recent changes to files could be lost if you have writeback journaling enabled for /system and you rebooted within (dirty expire + dirty writeback) / 100 seconds. A normal reboot that spends 5-10 seconds dumping and getting everything written to disk should be fine though. IF the new busybox' "mount" applet/function is incompatible or broken or outdated, a mount failure could occur leading to data loss. Backup toolbox mount in /system/bin should be enough to save this though, so I'm sticking with my diagnosis of a "SELinux gotcha".
Hope this helps, nothing worse than losing busybox or su functionality. As a side note, in case this problem takes a few days to figure out, check out Terminal IDE if you haven't before. It is definitely a nice busybox replacement to say the least if you need backup/better primary tools, at least temporarily. It's probably the most valuable app/terminal/busybox/Java/c/c++/ide/apkbuilder I've ever seen. ZERO ads, no net connection. You can get the latest apk off Google code, and there's a thread on xda by the creator Spartacus Rex. The tools and configurations are much more heavy duty than anything I've seen for Android. It has great well written tutorials to walk anybody through java, c, some shell stuff and utilizing ssh,telnet,iirc,git to make using android more like a linux machine. I've really gotten into this so I thought I would mention it.
7175 said:
... Busybox does not seem to have updated its tools that could support this, at least on Android. *Even Vanirs busybox 1.22.1.awesome doesn't have the ls -Z function. I was shocked to find out "Toolbox!" was actually useful for something, had a mental breakdown over it a couple months ago. [edit: After reading up on some busybox technical stuff, I found that busybox in its rarely seen full version can in fact be compiled with SELinux extended functions. The reason that almost every rom dev out there uses a busybox that doesn't include every function is portability, case rom to rom ;; older to newer vice versa ;& so that problems will be minimized ;; esac.
Click to expand...
Click to collapse
This must be the only sensible post on XDA, that has both Busybox and SELinux in the same post! Thanks.
Any ideas where to get a fully context featured Busybox? Tried to look in those tips you gave, but they're all outdated, i.e Busybox versions lower than 1.22.1.

ssh: No controlling tty

I have a rooted a GT-I9195 (SGS4-mini) done with CF-Auto-Root and the latest Busybox. I then decided to use the "Ssh server" from The Olive Tree, since it is simple, small, free, but unfortunately have ads. For on-device/local shell, I use the Android Terminal Emulator and everything works great, including su and shell environment.
However, I have a really strange bahaviour when connecting using ssh via WiFi, and trying to su.
First when connecting via ssh, I get the following message.
Code:
[SIZE=2]$ ssh -2 -4 -t [email protected] -p 50555
Authenticated with partial success.
[email protected]'s password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ $[/SIZE]
I have Googled this and there's little useful info. On one site they even say:
Code:
[SIZE=2]Getting a controlling tty
[B]How does one get a controlling terminal? [COLOR=Red]Nobody knows[/COLOR], this is a great mystery.[/B]
The System V approach is that the first tty opened by the process
becomes its controlling tty. The BSD approach is that one has to
explicitly call
ioctl(fd, TIOCSCTTY, ...);
to get a controlling tty.
Linux tries to be compatible with both, as always, and this results in
a very obscure complex of conditions. Roughly:
The [B]TIOCSCTTY [/B]ioctl will give us a controlling tty, provided that (i)
the current process is a session leader, and (ii) it does not yet have
a controlling tty, and (iii) maybe the tty should not already control
some other session; if it does it is an error if we aren't root, or we
steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that
(i) the current process is a session leader, and (ii) it does not yet
have a controlling tty, and (iii) the tty does not already control
some other session, and (iv) the open did not have the [B]O_NOCTTY[/B] flag,
and (v) the tty is not the foreground VT, and (vi) the tty is not the
console, and (vii) maybe the tty should not be master or slave pty.
[/SIZE]
Now this is not the end of the world, if it was not that it doesn't understand normal terminal control characters and in addition, when I do su, I loose the command prompt. However, using the "-i" (interactive) switch gets me the "#" prompt, but environment is still completely messed up:
Code:
[SIZE=2][email protected]:/ $ [B]su -c /system/bin/sh -i[/B]
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ #[/SIZE]
I've never had or seen this issue before. Any ideas?
(Also, where would I put a source to my .bashrc and make sure it runs when su'ing or ssh?)
PS. The phone is using a stock 4.2.2 SELinux kernel.
Code:
[SIZE=2]Device: Samsung Galaxy S4 Mini LTE (GT-I9195)
Board/Platform: MSM8930AB (Snapdragon 400)
Baseband: I9195XXUBML4
Kernel: 3.4.0-2340422
[email protected] #1
Build: JDQ39.I9195XXUBML4
SE: SEPF_GT-I9195_4.2.2_0022
ro.build.date: Sat Dec 21 01:46:00 KST 2013
ro.build.description: serranoltexx-user 4.2.2 JDQ39 I9195XXUBML4
[/SIZE]
I still have no idea of what's causing those error messages above, also because logcat is not telling us anything interesting either. Only as Warning from "System.err", but without any useful information. However, I have got some improvement in the terminal behavior when doing the initial ssh connection.
One problem seem to be that the TERM environment variable was copied from local machine (PC side) to remote server (Android phone), thus giving TERM=cygwin to the Android shell. This can be disabled or changed as follows.
Some relevant SSH options:
Code:
[SIZE=2]
-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The escape
character is only recognized at the beginning of a line. The escape charac-
ter followed by a dot (`.') closes the connection; followed by control-Z sus-
pends the connection; and followed by itself sends the escape character once.
Setting the character to "none" disables any escapes and makes the session
fully transparent.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-
based programs on a remote machine, which can be very useful, e.g. when
implementing menu services. Multiple -t options force tty allocation, even
if ssh has no local tty.
[/SIZE]
Some relevant SSH -o options:
Code:
[SIZE=2][B]RequestTTY[/B]
Specifies whether to request a pseudo-tty for the session. The argument may
be one of: "no" (never request a TTY), "yes" (always request a TTY when stan-
dard input is a TTY), "force" (always request a TTY) or "auto" (request a TTY
when opening a login session). This option mirrors the -t and -T flags for
ssh(1).
[B]
SendEnv[/B]
Specifies what variables from the local environ(7) should be sent to the
server. Note that environment passing is only supported for protocol 2. The
server must also support it, and the server must be configured to accept
these environment variables. Refer to AcceptEnv in sshd_config(5) for how to
configure the server. Variables are specified by name, which may contain
wildcard characters. Multiple environment variables may be separated by
whitespace or spread across multiple SendEnv directives. The default is not
to send any environment variables.
[/SIZE]
So by using the ssh -T option (which is equivalent to using '-o RequestTTY="no"'), we are disabling "pseudo-tty allocation" which doesn't work anyway, but with the effect of not forwarding local TERM to server, and thus setting it to default "vt100" which accepts backspace (but not insert). But a better way is to actually set the TERM variable on our own. This is done by simply adding it as a prefix to the ssh command like this:
Code:
[SIZE=2]TERM=[B]vt220[/B] ssh -t [email protected] -p 50555[/SIZE]
(This effectively, but temporarily overrides the local TERM value and forwards it to remote server shell.)
RanTime!
Since Google intruduced the SELinux/SEAndroid features, they have essentially fukced up the entire AOS ecosystem as based on good-old normal Linux environments and all the years of standards therein. Basically nothing works as before and as logically intended or preferred and I bet from now on, developers will have to spend a significant and expensive time, on just trying to setup their various developer environments and jump through the hoops of dikchead Google engineers, rather than on actual developing. A very sad story all thanks to the populist "security" eye-candy marketing.
The SU time!
Apparently after having read about the various quirks and issues in using an SELinux Enforced based AOS {4}, it seem that the issue from OP is probably due to one of 3 things or a combination thereof.
My su binary (SuperSU 1.94) is not yet handling SElinux properly
The SSHd server is not handling SELinux properly
Lack of properly set SSH and SHELL environment files on the server side
As for (1) I just have to wait and see. For (2) we can only test with other SSHd servers/solutions which I don't know what to use. (They're all, either not free or full of ads. WTF!) And finally, for (3) we can only test, since I don't have the source code...
Unfortunately listing the SuperSU (1.94) command line options is not very helpful, since they're rather poorly explained. While some of the option themselves just doesn't work (for me). It would have been great if @Chainfire could write a more detailed how-to {2} for all these options, but then again we should be extremely grateful he's written anything at all.
Code:
[SIZE=2]Usage: su [options] [--] [-] [LOGIN] [--] [args...]
------------------------------------------------------------------------------------
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-cn, --context CONTEXT switch to SELinux CONTEXT before invoking
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
-mm, --mount-master connect to a shell that can manipulate the
master mount namespace - requires su to be
running as daemon, must be first parameter
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default detected shell
-v, --version display public version and exit
-V display internal version and exit
Usage#2: su LOGIN COMMAND...
Usage#3: su {-d|--daemon|-ad|--auto-daemon|-r|--reload}
auto version starts daemon only on SDK >= 18 or
if SELinux is set to enforcing
Usage#4: su {-i|--install|-u|--uninstall}
perform post-install / pre-uninstall maintenance
[/SIZE]
References:
[1] [Chainfire G+] Next Android version: even more breakage
[2] [Chainfire] How-To SU (Guidelines for problem-free su usage)
[3] SuperSU Download
[4] [Google] Validating Security-Enhanced Linux in Android
From THIS very old post by @mirabilos , it is possible that command-line TAB-completion and up-arrow is not working on all mksh binaries. So perhaps we just need a new static mksh binary installed?
Tab expansion is pretty broken on BSD with xterm and GNU screen, but the same seems to work better on ssh’ing out to Linux, I wonder why, since all software involved is the same… except tput though. But it works like that and is usable. With post-R40 mksh, you can get about with even less hacks (more similarity to AT&T ksh).
Click to expand...
Click to collapse
However, this still doesn't explain why I have no controlling tty for ssh sessions.
Also I tested a new and different SSH server called SSHelper, which has more features and is better maintained, without ads, but is also 6 times larger at ~ 6MB, because of included OpenSSH, FTP and webserver log functionality. When logging in via ssh I get:
Code:
...
Server refused to allocate pty
Followed by an empty non-responsive connection.
Is this the same as […]this problem elsewhere? Man, I'm searching for ideas and keep coming back to your questions all over the 'net
To clarify, I talked to someone at Google; they renamed mksh into just sh lately, but this should have no adverse effect. They currently ship R48 and “would have updated it if I knew there was a new version”. That being said, the code of the shell itself is not at fault here.
The “no controlling tty” message here is a red herring: you do not have access to a tty at all, let alone a ctty
As I said elsewhere, use “ssh -t” and either change the SELinux policies to allow pty/tty pair allocation, or disable it (possibly set it into permissive mode).
@mirabilos: Yes, thanks for that info. I haven't updated this thread since I started it, in anticipation of a writeup about SELinux. However, that proves to be a little over my head, so it will take some time. What is clear though, is that the above problem is connected with the SEAndroid protection mechanisms, which in turn have been mangled and incorporated into Samsungs KNOX.
Also I have been busy making the SSHelper support thread:
[APP][INFO|SUPPORT] SSHelper (The free Android SSH Server Application)
There I have also added a small section about mksh.
@ E:V:A - I recently put together a little package containing all necessary bins/scripts to create a SSH server (via dropbear and dropbearkey) (properly secured, not public) and connect with a SSH client (ssh). The package also contains bins/scripts to create a Telnet server (via utelnetd) and connect with Telnet client (via "static busybox" telnet). Everything works with superuser that I've tested. Linked in my signature and attached to post as well.
Instructions (for anyone who sees this and would like a guide)::
Basically just extract it anywhere with:
Code:
tar -xf easy.ssh.and.telnetz.clients+servers.tar.gz
(if it's in /sdcard/Download which is probable, do "cd /sdcard/Download" then run the above)
Change directory inside the folder:
Code:
cd ./ssh.telnetz
There are 6 scripts: ssh.start(connect to ssh server via ssh), sshd.start(create ssh server), ssh.kill(kill ssh processes and remove ssh server keys), and... 3x telnet scripts for the telnet equivalents.
Running scripts and optional parameters:
Code:
./telnetd.start [ shell ]
e.g. TELNET_PORT=8080 ./telnetd.start /system/bin/mksh
./telnet.start [ ip port ]
e.g. ./telnet.start 192.168.0.3 8080
./sshd.start [ <dropbear_flags_and_options ]
e.g. ./sshd.start (default port is 8090)
./ssh.start [ ip port shell ]
e.g. ./ssh.start 192.168.0.3 8090 /system/bin/mksh
Default ip is the loopback 127.0.0.1 so you can test running a server and connecting to it on your phone at the same time. Just change params as described above to connect from/to your phone (phone is client/server).
***As far as I have tested on Android 4.4.4, this works perfectly as root or restricted user. You can get a su'd ssh shell by starting the sshd.start with /system/xbin/su or just entering su after you've connected as a restricted user.***
I've finally found a work-around for the crippled /dev/pts job-control and su combination. There are two small problems that combines to this issue.
1. The SELinux policy is screwed up by Samsung. And others?
2. The /dev/pts is mounted wrong by default.
The work-around:
Make sure you're device is already in Enforcing mode, so that you get the proper su prompt (#).
1. Open terminal session 1.
Code:
[SIZE=2]
## On Terminal 1
ssh -2 [email protected] -p 2222
$ su -c /system/bin/sh -i
# su 0 setenforce 0
# umount /dev/pts
# su -cn u:r:init:s0 -c "busybox mount -t devpts -o rw,seclabel,relatime,mode=620,gid=5 devpts /dev/pts"[/SIZE]
2. Now go to Terminal 2 and login:
Code:
[SIZE=2]## On terminal 2
ssh -2 [email protected] -p 2222
$
[/SIZE]
(You now have job-control but no su possibility.)
3. Now go back to Terminal 1 and enable Enforcing mode:
Code:
[SIZE=2]## On Terminal 1
# su 0 setenforce 1
[/SIZE]
4. Now go back to Terminal 2 and escalate to su:
Code:
[SIZE=2]## On terminal 2
$ su -c /system/bin/sh -i
# [/SIZE]
Unfortunately if you exit the su (#) shell, you'll have to repeat steps 2-4 of the procedure.

Making world-readable and world-writable files

tl;dr: working as root, I want to create a file that is world-readable.
Background: I'm using sshdroid and sshfs to access my phone, and termux on the phone itself. Sshdroid is configured to let me log in as root (ssh public key, not password), which is useful for other reasons. Working in sshdroid, I want to be able to create a file that is readable from termux (and other apps, notably tasker).
Example interaction (I have previously set directory permissions to allow access):
sshdroid> echo aaa > foo
sshdroid> chmod 644 foo
termux> cd /data/data/berserker.android.apps.sshdroid/home
termux> cat foo
cat: can't open 'foo': Permission denied
termux> ls -l foo
-rw- r-- r-- 1 u0_a202 u0_a202 4 Feb 10 00:55 foo
This seems to be SELinux-related, or possibly something to do with ACLs or extended attributes (lsattr shows nothing interesting; getfacl doesn't seem to be available in termux and sshdroid so I can't check that).
Experimentation shows that I can do "touch foo" in termux, then move foo to sshdroid's home and chmod it to 644. That works. But if I want to use sshfs via sshdroid to move a bunch of files to the phone, that's not a practical approach.
I'm guessing that SE Linux Switch or SE Linux Mode Changer would solve the problem, but in my usage scenario it would be suboptimal to have to reboot whenever I wanted to use sshfs, and likewise it seems suboptimal to permanently disable SELinux.
I'm thoroughly experienced in Unix/Linux but not in SELinux. So I'd love it if somebody were to point out a glaringly obvious solution.

Categories

Resources