I'm trying to resolve an SSH connection issue on an Android phone running SELinux in "Enforcing" mode. The problem is that any SSH connection that tries to allocate a pseudo-terminal (/dev/pts etc) is denied permission, leaving my connection without a controlling tty. Practically this means that I loose the ability to use normal terminal control for editing, command history, CTRL characters etc.

Presumably this means that SELinux is preventing the SSH daemon from opening /dev/ptmx.

I have no idea how to remedy this highly annoying situation, from within SSH server device (phone).

I'm running SSHelper on a non-priviledged port 2222 on a Samsung S4 using an SELinux Enforcing AOS 4.2.2 version. The weirdest thing is that I have root access using su under "Enforcing", but when I disable "Enforcing" and go to "Permissive", everything works in terminal, but I can no longer use su to gain root! (Simply no reaction and no error message.)

So there must be a way to control this under SELinux, but where and how?

Or is this a triviality and that I have only missed something?

For SSH connection in Enforcing mode, I use:

$ ssh -2 dummy@ -p 2222
SSHelper Version 6.3 Copyright 2014, P. Lutus
dummy@'s password:
PTY allocation request failed on channel 0
Linux 3.4.0-2340422 armv7l

This gets me a non tty shell with no prompt, severely limiting any editing possibilities.

PS. I have already tried with ssh -t ..., no go.

  • Hm. Only thing I can find about SELinux for Android. It does have some information on changing the SELinux policy though this appears to involve rebuilding some part of it… maybe contact its developers and ask for help? Also, did you ask the SSH developer? (Of course, switching to permissive would fix this.)
    – mirabilos
    May 30 '14 at 16:55
  • I wrote a partial answer to mention that opening /dev/ptmx is how the SSH server creates a terminal, and that's presumably what SELinux is restricting. I don't know how to change the SEAndroid policy — I presume that it's made purposefully difficult, since smartphone manufacturers tend to dislike allowing users to control the device that they supposedly own. @mirabilos May 30 '14 at 18:26
  • Huh. I put a bounty on this, and even that was not enough to find someone who knows (the bounty expired without someone to award to(. Looks like the thing to do, at the moment, is to disable SELinux enforcing.
    – mirabilos
    Jun 7 '14 at 20:00
  • Yes, I'm very surprised to see that nobody else is reporting any similar problems elsewhere. I'm starting to think that this must be a Samsung policy implementation error or possibly worse, KNOX policy interference. The device above, still has KNOX enabled (i.e. not removed), but is not used in any way. My next step will be to remove KNOX, and see what happens, although I'm not a big fan of completely removing stock apps. The risk with doing that is that if KNOX leaves a buggy policy file behind, we'd probably never know about it.
    – not2qubit
    Jun 11 '14 at 12:51
  • I have since learned that this issue originates from a combination of an improperly configured SELinux policy and having /dev/pts mounted wrong by default. The fix involve opening 2 terminals at once and re-mounting /dev/pts with the right permissions.
    – not2qubit
    Oct 1 '14 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.