To make Tiny Core Linux a superfortress of security...

[lolouis]

These are some of the things which have resulted from making the changes discussed above.
First of all, by including the boot parameters "superuser secure protect", the system asks for a new password for user "root" and for "encryption" each time it boots up, and that's not what I expected. I'd like to have the user passwords permanently written to /etc/shadow.
Are these boot parameters perhaps meant to be run only one time? (right now I have TCL on a hard drive partition [not booting in ram] so the changes would stick after the first time, I think.
The most disconcerting thing is that the password given for "encryption" (as a result of the "protect" boot code) is written in plain text in the file /etc/sysconfig/bfe, which is world readable. Is this meant to be this way??
Another thing to be corrected is that, after creating a non-privileged user (lo) and entering that username and password at the login prompt, I get:

"lo is not in the sudoers file. This incident will be reported."

and the system prompts for the password again. Entering the password again gets the same message ad infinitum, but pressing CTRL-C three times finally logs user lo in with the message:

"Sudo: 3 incorrect password attempts"

So, users created with adduser are somehow erroneously expected to be in the sudoers file. What needs to be changed to correct that?

And there is still the syntax error message when logging in as root:

login [4180]: root login on 'tty1'
-sh: syntax error: unexpected "fi"
root@box;~#

Will someone in the know tell me at what place in /etc/init.d/tc-config I need to remove the "unexpected 'fi'" to get rid of this one? Many thanks.

[curaga]

First of all, by including the boot parameters "superuser secure protect", the system asks for a new password for user "root" and for "encryption" each time it boots up, and that's not what I expected.

Protect should be there every boot, how would you decrypt your previous backup otherwise? The secure code is more intended for live boots, as it indeed sets the passwords on every use. For a permanent install, use it once, and add the relevant files to your backup during that run.

The most disconcerting thing is that the password given for "encryption" (as a result of the "protect" boot code) is written in plain text in the file /etc/sysconfig/bfe, which is world readable. Is this meant to be this way??

No, it should be tc:staff 640. An oversight, but not terrible considering the indended audience of the backup encryption (ie. offline inspection of your disk).
If you have N of logged in shell users at a time, they can see your processes and arguments anyway. And when you logged in, how long you've been idle, etc. Protection against other current users was not the goal there, but will tighten that.

"lo is not in the sudoers file. This incident will be reported."

Startx uses sudo. The X stack is tuned for user tc here, other users would only work well by default via the shell/ssh/etc.

And there is still the syntax error message when logging in as root:

login [4180]: root login on 'tty1'
-sh: syntax error: unexpected "fi"
root@box;~#

That is a result of your modifications, I see no such message. And since it's after login, it must come from one of the login files (check /root/.profile).

[newbody]

I know too little to be of help with setting up a secure TCE.
But from a complete newbie perspective one also would want a log of break in attempts that allert one that somebody target your IP numbers and whom that is and what programs they use doing it and how many hoops they used to got through some anonymity process and and when it was and for how long.

A kind of alarm or warnign message they are at it so one can shut down and use another computer or another OS or somethign and see  if they gave up on it seeing one reacted instantly to their attempt?

My naive thoughts.

[tinypoodle]

"lo is not in the sudoers file. This incident will be reported."

Startx uses sudo. The X stack is tuned for user tc here, other users would only work well by default via the shell/ssh/etc.

From the manual of Xvesa:

Xvesa runs untrusted code with full privileges, and is therefore a fairly insecure X server. The Xvesa server should only be used in trusted environments.

Very old news...   

[tinypoodle]

I know too little to be of help with setting up a secure TCE.
But from a complete newbie perspective one also would want a log of break in attempts that allert one that somebody target your IP numbers and whom that is and what programs they use doing it and how many hoops they used to got through some anonymity process and and when it was and for how long.

A kind of alarm or warnign message they are at it so one can shut down and use another computer or another OS or somethign and see  if they gave up on it seeing one reacted instantly to their attempt?

My naive thoughts.

FWIW, booting with 'syslog' will show all attempts of usage of 'sudo' in /var/log/messages.

[lolouis]

"lo is not in the sudoers file. This incident will be reported."

Startx uses sudo. The X stack is tuned for user tc here, other users would only work well by default via the shell/ssh/etc.

Actually this takes place in the shell upon bootup (I've disabled automatic startx in /home/tc/.profile), so I don't think it has anything to do with the X stack...

[newbody]

I know too little to be of help with setting up a secure TCE.
But from a complete newbie perspective one also would want a log of break in attempts that allert one that somebody target your IP numbers and whom that is and what programs they use doing it and how many hoops they used to got through some anonymity process and and when it was and for how long.

A kind of alarm or warnign message they are at it so one can shut down and use another computer or another OS or somethign and see  if they gave up on it seeing one reacted instantly to their attempt?

My naive thoughts.

FWIW, booting with 'syslog' will show all attempts of usage of 'sudo' in /var/log/messages.

thanks I will try to use that then Sad that Xvesa are that insecure!

[Guy]

http://wiki.tinycorelinux.com/Firewall

[newbody]

Thanks I study it tomorrow and try to implement it as good as I can. Much appreciated.

[Guy]

I know too little to be of help with setting up a secure TCE.
But from a complete newbie perspective one also would want a log of break in attempts that allert one that somebody target your IP numbers and whom that is and what programs they use doing it and how many hoops they used to got through some anonymity process and and when it was and for how long.

A kind of alarm or warnign message they are at it so one can shut down and use another computer or another OS or somethign and see  if they gave up on it seeing one reacted instantly to their attempt?

My naive thoughts.

You can set up Iptables to record everything coming into your computer when you are on the internet. If you record them all, there are many every second; too many to have time to read. You also finish up with large files when you record this.

In some situations, you can differentiate between what you requested, and what has been sent that you did not request.

You don't want anything you did not request coming into your computer, so you use Iptables to prevent it.

If you do that, you know something was sent, and the IP address it came from, but not what it would do if you let it into your computer.

Many things would be harmless. Many would target Windows, and not affect Linux. Many would be sent by malware on a computer, and the user would not know it was sent.

There are more coming from China than any other country.

In the end, it is simpler to prevent anything coming into your computer that you don't want, and not bother recording it. The Tiny Core firewall is ideal for that.

[lolouis]

And there is still the syntax error message when logging in as root:

login [4180]: root login on 'tty1'
-sh: syntax error: unexpected "fi"
root@box;~#

That is a result of your modifications, I see no such message. And since it's after login, it must come from one of the login files (check /root/.profile).

Curaga, I finally realized that there was nothing wrong with /etc/init.d/tc-config's syntax and that the syntax error message was indeed caused by some modifications I had made in /root/.profile and then forgot about it. My apologies about my blabberings about poor syntax in tc-config, which I have removed from this thread. Thanks for not making a fool out of me by replying to my earlier non-sense, which you could have easily done. Thanks for your help, which I very much appreciate.

[curaga]

No problem

[lolouis]

Thanks...

So, here's the thing... I realize why TCL is built the way it is...it is beautiful and elegant in the way its functionality is achieved with so little code, and it is perfect as it is for its intended scope.
I would like to achieve something extra with it, and I hope I'll find the help I need to make it happen on this forum. Let's call it "modifications for the security paranoid." It will also be an invaluable learning experience about the inner workings of TCL, to help understand what makes it tick.

Here's what I'd like to do. To have available two versions of TCL: one, the original TCL, just as it is plus the wireless and firewall stuff I've already successfully added to it, mainly used for the purpose of downloading extensions so as to build the system I want. And a second version, built with the various extensions I need downloaded via the first version but with all the "user tc" stuff removed, no "staff" group, no liberally permissive busybox, none of the extensions and persistency stuff requiring requiring privileged permissions, none at all of that but just two users, "root" and a non-privileged one, "lo," with the non-privileged one capacitated to use Xvesa and to surf the web with NO sudo rights.

The first version I already have, which again is TCL as is plus a functioning wireless and firewall.

These are the steps I've already taken toward building the second version: First of all I have created a privileged user, root, and a non-privileged one, lo. (After this step, with no further modification, user lo would not be able to start Xvesa. Logging in as lo and entering 'startx' would result in being asked for a password and none of the passwords available on the system would work.)
After that, I have removed ALL "user tc" files and directories and any reference to that user system-wide, and also stuff concerning persistent changes and the downloading and storage of extensions. Have transferred folder .wmx (SystemTools) from /home/tc to /home/lo, along with fluff.conf. Have commented out the SUID stuff in /etc/busybox.conf. Have also modified minor stuff here and there, quite a few details to now list here from memory. I have modified the /etc/init.d/tc-config file as follows:

USER="tc" changed to USER="lo"

then commented out lines 8 through 20:
#TCEDIR="/tmp/tce"
......
#}

commented out lines 183 through 230:
#wait4Server() {
......
#}

commented out lines 233 through 290:
#modprobe -q squashfs 2>/dev/null
.......
#mkdir -p /home/"$USER"

commented out lines 293 through 314:
#if [ -n "$TCVD" ]; then
.......
#fi

commented out lines 317 through 343:
#unset HOME_SETUP
.........
#fi

commented out lines 345 through 373:
#[ ! "$HOME_SETUP" ] && setupHome
........
#fi

commented out lines 417 through 460:
#[ -d "$TCEINSTALLED" ] || mkdir "$TCEINSTALLED"
........
#fi

commented out lines 472 through 577:
#if [ -n "$NORESTORE" ]; then
........
#fi

commented out lines 494 through 503:
#if [ -n "$SECURE" ]; then
........
#fi

I learned that most of the stuff in /etc/init.d/tc-config concerns the downloading of extensions and persistent changes. TCL is really an INCREDIBLY, WONDERFULLY SIMPLE OS, highly functional, even when reduced to its very core apart from the extensions and persistent changes stuff. I love it!

Now, booting the system after removing all the functions listed above - this is great! - almost everything works the way I intended, with just a few minor quirks that need to be taken care of.
Logging in as root works just fine. Starting Xvesa as root with 'startx'...Xwindows starts just fine but with a black desktop (no color and no logo). Stuff works ONLY when the mouse pointer is placed on the opened window of that particular item. For instance, when I open an aterm console, everything seems to be working fine as long as the mouse pointer is placed over that particular window, otherwise the console becomes non-responsive. Same thing with applications such as editor (fired from the console), file manager, panel, mount, etc. (as long as the mouse pointer is placed on their windows). The X button for clicking an application closed which usually appears at the upper right corner of a window is no longer there. But application windows can still be closed by clicking on File -> Exit or by pressing the ESC key while the mouse pointer is placed on their windows.
The EXIT icon (which in standard TCL reboots the system) no longer works, but Xwindows is easily exited with CTRL-ALT-BACKSPACE, which will return you to the original console command prompt you started X from.
So far so good, aside from the above minor quirks which I'm sure should be easily taken care of if someone here with the required know-how gives me a little help.

Now, when I log in as non-privileged user lo, things are much different. First of all, upon entering lo's password, the screen goes blank - the command prompt disappears. Pressing CTRL-C brings the prompt back and I'm now logged in as "lo":

lo@box:~$

All console commands seem to be working just fine, but when I enter 'startx' absolutely nothing happens for a long 80 seconds. After 80 seconds - lo and behold! - the normal TCL Xwindows desktop comes up with color, logo and all.
The applications seem to work fine except, as in root's case, there's no X button on the upper right corner of the applications' windows to click them closed, AND aterm doesn't work at all...clicking on the aterm icon produces an aterm console (window) for a split of a second which then disappears.
The EXIT icon, as in root's case, also doesn't work, and Xwindows can again only be exited with CTRL-ALT-BACKSPACE.
After exiting Xwindows and being returned to the command prompt, entering 'startx' again takes 80 seconds to bring up Xwindows.
At the console, unprivileged user lo's access permissions are properly limited, the way I want them to be. It can't mount/umount stuff and so forth and so on. That's the unprivileged kind of user I like to surf the web with, and now TCL is a very secure system for someone as paranoid as I am . I have rebuilt busybox with a regular busybox executable with permissions set to 104755 which includes most of TCL's programs, and a second busybox-suid executable with permissions set to 104711 for mount, umount, su, crontab, passwd, ping and traceroute.
With this setup, programs like sudo and visudo can be safely gotten rid of, as they are no longer useful on this system.

So, I'm now half way in reaching the goal I set for myself when I started this thread. Could someone please help me resolve the few quirks reported above? This is being a great learning experience for me. I hope it will have some value also for some of you reading this thread.

[lolouis]

There is also the question of Xvesa running untrusted code with full privileges....thus making it an insecure X server.
Question: What X.org packages do I need to download in order to replace Xvesa and how do I go about removing Xvesa and replacing it with Xorg? Right now I can't download extensions from within TCL, so I'll have to do the replacement manually.
Will X.org server, fonts, binaries and libraries suffice, or what else do I need? Many thanks.

[Juanito]

You can use microcore, omit the Xvesa.gz package and use the Xorg-7.5 extension and deps instead.