Quote:
Originally Posted by frostschutz
Of course, if you DO set the suid flag and the owner is wrong, then it really bites you as suddenly you execute stuff as nobody instead of root. Here suid causes problems instead of solving them.
|
And busybox can bite you in more than one way....
But yes, if you don't make it suid
root, then it suddenly causes problems instead of solving them. That's why I made it suid root:
chown root:root /bin/busybox
chmod +s /bin/busybox
It is in fact bizarre that kobo readers have several files which belong to a user id number which is not even in the /etc/passwd file, eg: essentially nobodies rather than root.
Quote:
|
suid on busybox is a bad idea. It would suid _everything_, not just passwd. So nobodies can overwrite files etc. etc. etc.
|
Right now the kobo runs all software as root, as you yourself note.
So, If I just hand my kids the vt52 terminal directly after a framebuffer switch to the virtual terminal (the whole purpose of this thread
), by default the shell will come up with uid set to the process that called it; eg: uid = root, and path= /. So -- if my kids do something sily like rm -rf *, the whole Kobo gets destroyed, but even if they are careful game programs like frotz do not run because they test and refuse to run if logged in as root.
On the other hand, if I use a special command I created, eg: session to log them in as a non root user without busybox; I can't possibly get back to being root user from the terminal or do sudo commands to start wifi, etc. with -- Unless I can login as root from a non-root account.
But logging in as root requires busybox to be suid root.
It's messy, but in order to flexibly hack on the system without risking too much damage to the Kobo I really needed the ability to login as root (run su from non-root terminal) and log back out again to plain user, and have directories that are relatively safe for experimentation.
So: I partitioned an external SD card into three parts using fdisk. Partition one is an of type 0x0b, msdos vfat. It's a mere 2 megabytes, and contains only an autorun.sh script, and a handful of binaries that are nearly always in use -- such as bash, vt52u (the terminal), the morse code virtual keyboard driver. etc. Highly used and high risk scripts.
eg: Things that I don't want to have to 'kill' in order to unmount a partition, or remount it as readonly.
This has two desired effects, the Kobo sees an msdos partition and so nickel/hindenburg doesn't complain continually about the sd card being unreadable and needing to be formatted.
And it gives me a place to put executables which the kobo will auto-mount read-only root ownership for booting my auxilliary system.
But because msdos does not support unix permissions, like suid, without globally setting them for all files as part of the mountpoint permssions -- I made two other partitions.
The second partition is another msdos partion (type 0x0b) called 'home', which is the default login directory for a non-super user account that I add to the kobo. It is again resistant to corruption due to msdos's nature under hardware resets, so is a good place to put experimental files and game save files.
I made it a partition, rather than a subdirectory in the first partition -- because vfat doesn't support unix ownership and I don't want to fight kobo's default actions in mounting /mnt/sd. So: The first partition the Kobo mounts however it wants, (superuser ownership readonly), but the second partion mounts rw and is owned by user 'home'. (I made its mount point /mnt/home).
And of course, the third partition I created is a ext2fs partition (type 0x83); I call it user, and I made it ext2 because that's the only generic unix fs that the kobo supports natively.
And I mount that partition read only on a directory I create called /mnt/user.
If I need to edit files on the user partition, I mount it rw, make the changes, and then remount it read only. Since my sysadmin tools run from the first dos partition -- this means I can either unmount or remount user as rw, without worrying about the partition being 'busy' on a perpetual basis. All programs on that partition can be terminated without killing my user terminal or admin programs.
So I put binaries like python-2.7.10, frotz, frobtads,sorry,battleship, etc. in that third partition.
And remount it readonly before trying to execute them -- so if the system crashes, and is rebooted, I don't have a corrupted ext2fs filesystem on my hands without an ext2fsck program available....
As a note for you:
Busybox itself allows choosing which programs run with suid permissions and which ones don't when it's owned by root. (By default busybox exits suid root before running it's internal applets unless instructed not to -- even if the suid bit is set on busybox as far as I know -- but I'm no expert...).
There is is a configuration file that you can add in /etc which will tell busybox when to reset the suid permission to a the originating uid (non superuser id) and when not to reset it -- all you need to do is create an extra configuration file in /etc called (drumroll) busybox.conf
Mine is like this:
Code:
[SUID]
su = ssx root.root
login = ssx root.root
and do:
chown root:root /etc/busybox.conf
chmod 600 /etc/busybox.conf
That's it -- the Kobo is happy to oblige multi users with those changes, and will only allow two busybox programs to run setuser id -- the rest must run as the id of the person calling busybox.
I thought about not making the kobo's busybox suid, and instead putting a copy busybox on a mounted external filesystem, but having two copies of busybox sort of defeats the memory management benefits of having all tools in a single image; for linux can share code memory images among many different instances of runnning busybox commands if it comes from the same file -- but not if from multiple files.
Hardlinks, unfortuantely, don't support different permissions on linux; so we can't make busybox suid under one name, and not suid under another.
Softlinks don't allow suid changes either.
(By the way, I just partially bricked my reader experimenting with that again and I even knew better! --- *sigh* time to drag out the sd card reader again or do factory reset ...
)
And although I can make the group permission sgid on busybox, but leave the owner permission as non-suid; I don't see how that would help. For I am not sure how a non-root user to could change to a new group without having an suid busybox in the first place.
It's sort of crazy that kobo has a busybox that is default user:group 501:1000 , which are not defined anywhere in /etc. Sloppy programming. But that's the way it is.
So -- the only alternative to changing the mode of busybox to suid root, that I see -- it to create a standalone setiud root program on my third partition, eg: a sudo program that is not part of busybox.
I'm pretty happy with the way busybox works when suid root is set for allowing a 'regular' user account, so I think I'm going to just keep using it; but the kobo does have one really irritating security feature which I think might be part of busybox, for it refuses to export LD_LIBRARY_PATH during the 'env' command execution, so that a user who wishes to make an autorun python script in the 'home' partition can't put '#!/user/bin/env python' at the start of the python script, because the kobo's version of ENV erases the system variable called LD_LIBRARY_PATH.
That prevents security breaches by replacing shared libraries with hacked ones, but it also prevents me from running pyhon in an autoscript as a regular user.
I suppose I could do "#!/usr/bin/env LD_LIBRARY_PATH=/mnt/user/lib python"
as the first line, but it seems that there ought to be a better way to do it that is less system dependent...
EDIT: Nope, even that solution causes the program to hang totally.
Apparently env can't handle people setting environment variables as part of a script start execution...
It works from the command line, but not as a script auto-start command.
EDIT: OOOOOH!
Check this out
Almost every unix out there puts a shell of some kind on /bin/sh. The system shell....
Busybox is no exception:
SO, watch this shell game -played over telnet exclusively on the AuraHD -- closely ---:
Code:
~ # echo $LD_LIBRARY_PATH
/mnt/user/lib
~ # export LD_LIBARY_PATH="/mnt/user/lib"
~ # login home
Password:
[home@AndrewsKoboHD ~]$ echo $LD_LIBRARY_PATH
/mnt/user/lib
[home@AndrewsKoboHD ~]$ export LD_LIBRARY_PATH="/mnt/user/lib"
[home@AndrewsKoboHD ~]$ /bin/sh -c "python"
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
[home@AndrewsKoboHD ~]$ /bin/sh -c "LD_LIBRARY_PATH=$LD_LIBRARY_PATH python"
Python 2.7.10 (default, Jun 30 2015, 20:30:05)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
If I set LD_LIBRARY path to itself, it works.
Busybox, a program named after a toy meant to entertain infants uselessly for hours... Good thing I don't actually have to have this program running by tomorrow...!
Code:
~ # login
AndrewsKoboHD login: home
Password:
[home@AndrewsKoboHD ~]$ echo $LD_LIBRARY_PATH
/mnt/user/lib
[home@AndrewsKoboHD ~]$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
[home@AndrewsKoboHD ~]$ sh
[home@AndrewsKoboHD ~]$ echo $LD_LIBARY_PATH
[home@AndrewsKoboHD ~]$
[home@AndrewsKoboHD ~]$ exit
[home@AndrewsKoboHD ~]$ echo $LD_LIBRARY_PATH
/mnt/user/lib
[home@AndrewsKoboHD ~]$ export quote="YES"
[home@AndrewsKoboHD ~]$ bash
[home@AndrewsKoboHD ~]$ echo $quote
YES
[home@AndrewsKoboHD ~]$ exit
[home@AndrewsKoboHD ~]$ exit
~ # echo $LD_LIBRARY_PATH
/mnt/user/lib
~ # export quote="yup"
~ # sh
~ # echo $quote
yup
~ # bash
bash-4.3# echo $quote
yup
bash-4.3# sh
~ #echo $quote
yup
Wow. So, in which shell is the LD_LIBRARY_PATH NOT found?
Pick a shell, any shell...