Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: lolouis on February 04, 2011, 10:21:28 PM
-
I looked into tc-config and, based on my greenish understanding of it, was glad for the glimpse into the possibility of getting rid of the tcuser user and of setting up a normal superuser and nonprivileged users so as to have more control over permissions and system security. :)
So, I renamed the file tcuser and created a few new ones in /etc/sysconfig, just to see how that would change things: user, host, superuser, secure, protect....and also a file named "noautologin" and commented out (probably redundant/unnecessary) "startx" in /home/tc/.profile....no idea if I understood the pointers in tc-config correctly, though.
Now I'm getting a login prompt at bootup....great...but what password do I enter for root? ???
If there is something about this whole affair in the documentation, would you please kindly point me to it, otherwise any tips you can give me in this regard (how to improve TCL security for the paranoid) would be greatly appreciated.
-
If you dont want X, use microcore instead of tinycore.
You can pass a 'noautologin' boot code.
You can add users, and set passwords.
Then add the following 4 lines to /opt/.filetool.lst
etc/passwd
etc/shadow
etc/group
etc/gshadow
-
There are a lot of aspects to security. Which are you concerned about?
Are you concerned about people who may hack into your computer from the internet, or people who have physical access to your computer?
If you are concerned about people who may hack into your computer from the internet, install and set up the Iptables firewall.
If you are concerned about people who have physical access to your computer, consider the following. You can take Tiny Core, or any other Linux live cd, run it on someone else's computer, and access all their personal files. The same thing can be done using operating systems on usb drives. Passwords do not stop that.
Passwords will stop people who don't know about that. For example, family members.
If you set up a password for logging in, the way Tiny Core is set up, after logging in, you can have root access without a password. To change Tiny Core, to that does not happen, is quite complicated.
For good security, you can encrypt any important files. Search the forum for that info. That will stop people accessing them from operating systems on cds and usb drives.
There are many other things you can do. For example, you can set up Tiny Core, so when you start it, the terminal is removed from the menu and wbar.
-
If you dont want X, use microcore instead of tinycore.
You can pass a 'noautologin' boot code.
You can add users, and set passwords.
Then add the following 4 lines to /opt/.filetool.lst
etc/passwd
etc/shadow
etc/group
etc/gshadow
I do want X, but with the option of logging into it as a nonprivileged user.
The 'noautologin' parameter has already been activated by my placing a file named 'noautologin' in /etc/sysconfig....
I will try adding the lines you suggested and report back tomorrow. Many thanks.
-
Are you concerned about people who may hack into your computer from the internet, or people who have physical access to your computer?
Hackers from the internet.
If you are concerned about people who may hack into your computer from the internet, install and set up the Iptables firewall.
I have done that already, and with a firewall script of my own writing. By the way, how do you suggest firing up the firewall script in TCL during the boot process?
If you set up a password for logging in, the way Tiny Core is set up, after logging in, you can have root access without a password. To change Tiny Core, to that does not happen, is quite complicated.
That's exactly what I want to do. I don't mind its being complicated...the more complicated it is, the more I stand to learn in the process. Would you mind giving a brief outline of how that can be accomplished, in your opinion? I'm sure that others here with similar concerns would love to read that.
Very educational indeed.
For good security, you can encrypt any important files. Search the forum for that info. That will stop people accessing them from operating systems on cds and usb drives.
Thank you, will look into that too.
There are many other things you can do. For example, you can set up Tiny Core, so when you start it, the terminal is removed from the menu and wbar.
Many thanks. Looking forward to your reply in re: "complicated" structural changes to make TCL more secure. To me, one of the most precious things in playing with TCL is what I stand to learn in the process. I am very grateful for those who, like you, take the time to answer questions such as these ones on this forum.
-
how do you suggest firing up the firewall script in TCL during the boot process?
To start the existing one during the boot process, you need iptables.tcz in On Boot, and add sudo /usr/local/sbin/basic-firewall to /opt/bootlocal.sh.
If you want to modify the firewall, I suggest you modify, /tmp/tcloop/iptables/usr/local/sbin/basic-firewall, then make a new extension.
To make a new extension you need the mksquashfs extension installed.
Using a file manager, create a new directory in /home/tc. Let's call it myext.
Create a new directory in /home/tc/myext. Let's call it iptables.
Go to tmp/tcloop/iptables. Copy the contents (the directory usr). Paste this to /home/tc/myext/iptables.
Put the modified file in /home/tc/myext/iptables.
Open the terminal and type:
sudo su
cd /home/tc/myext
mksquashfs iptables/ iptables.tcz
Using a file manager, remove the original from /tce/optional. Copy and paste the new extension to /tce/optional.
Keep a copy. Whenever you update extensions, it may be lost.
-
In the past, I have experimented with modifications to Tiny Core and extensions.
Some of the modifications I experimented with, did not work. In some cases, the computer would lock up.
At that time I had 3 or more partitions, with Tiny Core installed on each, and an entry in Grub for each. When one would lock up, I would be able to boot with another and fix the problem.
I now have several versions of Tiny Core installed, all on the same partition. menu.lst looks like this:
title Tiny Core 3.5rc1
root (hd0,0)
kernel /tc3.5rc1/bzImage quiet opt=hda1 tce=hda1 home=hda1 noautologin norestore
initrd /tc3.5rc1/tinycore.gz
title Tiny Core 3.4.1
root (hd0,0)
kernel /tc3.4.1/bzImage quiet opt=hda1 tce=hda1 home=hda1 noautologin norestore
initrd /tc3.4.1/tinycore.gz
title Tiny Core 3.3
root (hd0,0)
kernel /tc3.3/bzImage quiet opt=hda1 tce=hda1 home=hda1 noautologin norestore
initrd /tc3.3/tinycore.gz
Anyway, when experimenting with modifications, I suggest you have more than one version of Tiny Core installed, so you can fix things when something does not work properly.
-
User tc is a normal unprivileged user. I assume you are talking about the right to execute sudo without password.
This right is only for user tc, so if you create additional users, they will have no right to use sudo at all, not even with password.
The only way anyone could come in from the net is via access via the net. Thus you are free to run your browser and servers as another user, and so they only have access to that user's files. No sudo access like the tc user.
-
if you create additional users, they will have no right to use sudo at all, not even with password.
That is something I did not know. Which version was it introduced?
Many administrative tasks can still be done as a regular user.
-
If I was to set up an internet cafe, and I have no plans to, I would run two installations of Tiny Core, with two logins, but just one set of extensions.
The one for the customers, would load by default, without a password. I would remove anything from the wbar, I did not want the customers to access. I would have it remove the menu during start up. With what I have just learnt, it could be a user other than tc.
The one for administration, could be selected from a grub menu during boot, and require a password, so customers could not access it, and log in as tc.
Another option would be to use a live cd, or installation on a usb, for administration.
This same idea could be used in many other situations.
-
if you create additional users, they will have no right to use sudo at all, not even with password.
That is something I did not know. Which version was it introduced?
Many administrative tasks can still be done as a regular user.
It's always been like that, AFAICS. Any user has to be listed in /etc/sudoers for them to be able to use sudo. adduser only touches the passwd/group and shadow files.
Depending on whether you include the new user in group staff, they may have access to extensions, among other things.
-
If you are concerned about people who have physical access to your computer, consider the following. You can take Tiny Core, or any other Linux live cd, run it on someone else's computer, and access all their personal files. The same thing can be done using operating systems on usb drives. Passwords do not stop that.
Well done to point that out. ;)
That's where BIOS - or to a more limited effect HDD - passwords would come in.
-
Guy, from your menu.lst
noautologin
So if I don't add that one then I autologin obviously. Is it more secure then to not autologin.
And when it has booted. You have to boot in but what choices gets presented then?
What is the autologin logging in as? TC or Root or what?
-
Thank you Guy and curaga for your priceless contributions to this thread.
gerald_clark, you were right about the need to pass 'noautologin' as boot code. After adding those lines you suggested to /opt/.filetool.lst AND booting with code "noautologin" along with codes "user superuser secure protect laptop" (this also answers newbody's question), I was presented, right after bootup, with the options to enter a password for both root, user tc and encryption (which I did) and after that presented with a login prompt. Great!
HOWEVER, though both root and user tc can now login, I get the following screen errors.
For root:
login [4180]: root login on 'tty1'
-sh: syntax error: unexpected "fi"
root@box;~#
For user tc:
-sh: syntax error: unexpected end of file
tc@box:~$
So, if someone tells me where and how to correct these, I'll go ahead and do it myself. Also, if a developer reads this, he/she might want to make these corrections to the current TCL release, if applicable.
At that time I had 3 or more partitions, with Tiny Core installed on each, and an entry in Grub for each. When one would lock up, I would be able to boot with another and fix the problem.
Right now I have one hard drive partition fully dedicated to TCL. I am making changes to it from my main install of Slackware - much easier that way. If something goes wrong, I can always boot the original TCL iso in ram to compare things and restore the original settings if I need to.
Thank you, Guy, also for your firewall mini-howto....much appreciated.
User tc is a normal unprivileged user. I assume you are talking about the right to execute sudo without password.
Exactly.... The whole sudo thing makes me a bit uneasy. I wish sudoers could be done away with altogether on my system, but as you said:
This right is only for user tc, so if you create additional users, they will have no right to use sudo at all, not even with password.
The only way anyone could come in from the net is via access via the net. Thus you are free to run your browser and servers as another user, and so they only have access to that user's files. No sudo access like the tc user.
This is great. That was my initial concern, an intrusion via the net while operating as user tc on the net. However, the downloading of applications is still done via user tc, right? In which other ways does user tc, with its privileged status, expose the system to intrusion via the internet?
So the way to go to make TCL more secure is to create/use additional nonprivileged users to do whatever stuff one wishes to do on the internet.
Now a question from a purely educational standpoint.... I looked into /etc/init.d/tc-config more closely and a lot of stuff is mounted/made to be suid.... Why was this choice adopted, given its inherent potentiality for opening the system to intrusion? Was it for ease of use, for keeping it as small as possible, or what else? Is it conceivable to remove the suid/sudo capability from TCL and still have a working system after making a few adjustments? Many thanks.
If I was to set up an internet cafe, and I have no plans to, I would .....
Seems like a great idea for a kiosk utilization of TCL. :)
-
noautologin
So if I don't add that one then I autologin obviously. Is it more secure then to not autologin.
And when it has booted. You have to boot in but what choices gets presented then?
What is the autologin logging in as? TC or Root or what?
By default, you automatically log in as tc.
If you set up a password for tc (open the terminal and type passwd), or add a user (open the terminal and type sudo adduser user-name), and include the noautologin bootcode, you will be prompted for a user name and password when you log in.
You need to add etc/passwd and etc/shadow to backup. If you also add a group, include etc/group and etc/gshadow. I prefer to make a new extension containing these files. Making a new extension is discussed above in an earlier post. I don't use backup.
This provides security against people who have access to your computer. If they don't know your password, they can't run Tiny Core.
-
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.
-
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).
-
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.
-
"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... :D
-
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.
-
"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...
-
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!
-
http://wiki.tinycorelinux.com/Firewall
-
Thanks I study it tomorrow and try to implement it as good as I can. Much appreciated.
-
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.
-
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.
-
No problem :)
-
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.
-
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.
-
You can use microcore, omit the Xvesa.gz package and use the Xorg-7.5 extension and deps instead.
-
Possibly graphics driver modules, depending on card.
-
You can use microcore, omit the Xvesa.gz package and use the Xorg-7.5 extension and deps instead.
Thanks for pointing it out! Will do that.
-
OK. Following Juanito's advice, I started with a fresh installation of microcore, unpacked on hard drive and booted there (I guess "scattered" is what you call it) to which I (manually) added Xlibs and Xprogs (but not Xvesa), and later Xorg-7.5, Xorg-7.5-lib, Xorg-7.5-bin, Xorg-fonts and Xorg-7.5-xgi.
By the way, unpacked, microcore was a mere 9.5 MB. After adding the above, it has grown to over 50 MB. WOWOW! I guess that's a price the security paranoid must be prepared to pay :o (and the reason why tinycore compromises with the much less desirable Xvesa - to remain small).
Now, with no special booting codes, the new system boots into a shell with user tc logged in. Entering 'startx' gets the following error message:
cat: can't open '/etc/sysconfig/Xserver': No such file or directory
So, I added a file named Xserver to /etc/sysconfig with "Xorg" written in it and rebooted the system.
At the end of the booting sequence the system now hangs for 10 seconds (it seems about to start the X server) but then gives the following message and boots, again, to a shell console:
hsetroot[3702]: segfault at 88 ip 08049cb4 sp bf927350 error 4 in hsetroot[8048000+4000]
tc@box:~$
Have I forgotten to add some required extension, or does anybody know what's going on here?
-
the reason why tinycore compromises with the much less desirable Xvesa - to remain small
compromises?
That is a matter of choice and preference, I couldn't see any compromise there at all, and e.g. for me would be one of the basic criteria in choosing a system, despite that I would admit that under many circumstances I would prefer the newer Xvesa extension and have occasionally even used Xorg, but it can make sense that whatever is smaller is chosen as default.
"the much less desirable Xvesa" according to your preferences which you make it sound like they would be shared by everyone...
-
Have I forgotten to add some required extension, or does anybody know what's going on here?
I've never tried this in scatter mode, but - based on tc-3.4 - if you do the following in "normal" mode, things should work:
1. Xprogs.gz, Xlibs.gz in /tce
2. flwm.tcz, wbar.tcz, Xorg-7.5.tcz (and deps) in /tce/optional and set "onboot"
You can subtitute flwm/wbar with the wm of your choice.
-
"the much less desirable Xvesa" according to your preferences which you make it sound like they would be shared by everyone...
Not my intention... I was of course expressing my own personal view, which is one that places much importance on security... Xvesa being insecure when compared to Xorg... Hence, based on my personal preference, viewing the use of the less secure Xvesa as a trade for the sake of keeping the system small. Nothing more was implied... A question of semantics, I guess. :)
-
Have I forgotten to add some required extension, or does anybody know what's going on here?
I've never tried this in scatter mode, but - based on tc-3.4 - if you do the following in "normal" mode, things should work:
1. Xprogs.gz, Xlibs.gz in /tce
2. flwm.tcz, wbar.tcz, Xorg-7.5.tcz (and deps) in /tce/optional and set "onboot"
You can subtitute flwm/wbar with the wm of your choice.
Scatter mode shouldn't make any difference. I didn't do the flwm.tcz and wbar.tcz....I guess that's where the problem is at. Also, it might be deps... Can you tell me what the deps for Xorg-7.5.tcz are, because I'm in a situation where I'm forced to install the files manually. Thanks for your help. :)
-
As per the dep file, the basic deps are:
pixman.tcz
fontconfig.tcz [-> expat2.tcz]
openssl-0.9.8.tcz
Xorg-7.5-bin.tcz
Xorg-7.5-lib.tcz
Xorg-fonts.tcz
However, depending on your chipset, you might need more than this.
-
I went to the current download repository but the info files for both flwm.tcz and wbar.tcz show that these extensions refer to earlier versions of tiny/microcore. So what I did is I copied the equivalent files directly from tinycore-3.4.1 to microcore-3.4.1 to make sure everything would fit right.
However, upon booting up, I now get the same hsetroot error message. It must be a missing dep.
As a matter of fact, something did come up the very first time I booted microcore after installing Xorg referring to a missing libpixman-1.so.1 - and I see the same in your list of basic deps. So, I'm pretty sure that after adding these missing deps everything will be fine. I'll do that tomorrow.
I really appreciate all your help, Juanito. Thank you so much!
-
"the much less desirable Xvesa" according to your preferences which you make it sound like they would be shared by everyone...
Not my intention... I was of course expressing my own personal view, which is one that places much importance on security... Xvesa being insecure when compared to Xorg... Hence, based on my personal preference, viewing the use of the less secure Xvesa as a trade for the sake of keeping the system small. Nothing more was implied... A question of semantics, I guess. :)
We appear to look at things from the opposite POV:
To me it would be a tradeoff to imminently and constantly sacrifice the need of only a friction of resources and a significant permanent gain in performance (at least so without KMS which I haven't happened to use so far) for the potential theoretical security to be gained.
On a sidenote:
I would estimate the loss of security when attempting to run TC in scatter mode (in comparison to default mode) to amount to a multiple of the increase of security which could be gained by replacing Xvesa with Xorg.
-
I'll do that tomorrow.
@Juanito
I've added all the listed deps (including expat2.tcz) and now the system boots fast into Xwindows, gets the blue screen with TC logo...but NO ICONS and a frozen mouse pointer in the center of the screen. It stays frozen that way.
CTRL-BACKSPACE got me to a console prompt...I ran 'sudo ldconfig' (did not know what else to do) and restarted Xorg with 'startx." Same result as before.
I have, on this particular computer, an ATI Rage 128 Pro video card. I looked into /usr/local/lib/X11/modules/drivers and the ati_drv.so and r128_drv.so drivers for the card are right in there.
Possibly a configuration problem? What could this be?
-
We appear to look at things from the opposite POV:
To me it would be a tradeoff to imminently and constantly sacrifice the need of only a friction of resources and a significant permanent gain in performance (at least so without KMS which I haven't happened to use so far) for the potential theoretical security to be gained.
Agreed, definitely....we look at the same thing from two different perspectives.
On a sidenote:
I would estimate the loss of security when attempting to run TC in scatter mode (in comparison to default mode) to amount to a multiple of the increase of security which could be gained by replacing Xvesa with Xorg.
If you had read my earlier posts in this thread, you'd have known that I currently have TCL in scatter mode only for the easiness it affords for making the needed changes until the time comes for repacking. I'd never use it online on a regular basis in scatter mode. It will be run in ram (TC's standard way) on my modern machines and let's see how things turn out to be with my 96MB-RAM laptop.... If too much to handle for the old chap, I'll run it there as a compressed filesystem (unionfs + LZMA-compressed squashfs, or perhaps aufs + LZMA-squashfs) - the way some LIVE-CD distros are run.
Don't forget that with Xvesa any malicious code that gets its way into your machine while you are online automatically acquires root privileges. With Xorg, on the other hand, you can surf online as an unprivileged user and thus limit that sort of damage.
That said, your POV is not without merit, of course. It all depends on what you do with your computer. For instance, for doing general project research on the web or engaging in light talks with your friends in chat rooms (provided nothing valuable is stored on your machine), sure, I have no problem with it at all, that's the way to go... But for more sensitive tasks, say, as online banking (and I can think of several other highly sensitive tasks), that's were the extra security that comes with Xorg really pays off. Again, it depends on what you intend to do (and do) with your computer.
-
Ah, ok, makes much more sense to me now, though I have my doubts about easiness of a scatter mode exercise.
Isn't surfing as unprivileged user dependent on PID owner of app accessing the net, rather than on PID owner of X?
Not sure how X is related to that, as there are many apps (including browsers) which can access the net without presence of any X server.
-
Ah, ok, makes much more sense to me now, though I have my doubts about easiness of a scatter mode exercise.
Very easily done...at least I have much practice with this sort of thing.
Isn't surfing as unprivileged user dependent on PID owner of app accessing the net, rather than on PID owner of X?
My understanding is that if you, for instance, surf with the opera browser in Xorg as an unprivileged user and someone gets to own your account through it, the access they have to the system and the damage they can do to it is limited to what you can do as that unprivileged user. Not so with Xvesa.
Provided, of course, that you actually have the possibility of logging into the system as a solidly unprivileged user....which is the reason motivating the changes I described in one of my earlier posts.
Not sure how X is related to that, as there are many apps (including browsers) which can access the net without presence of any X server.
Of course. But here the premise is that you have installed Xwindows on your system (be it Xorg or Xvesa) to actually do stuff with it on the web. Otherwise, why would you have installed Xwindows at all? :) My only reason for having Xwindows on a minimalist OS is the possibility if affords to use a graphic browser....otherwise I could very well do without it.
My friend, it's a pleasure talking with you. My reason for being here, however, is to achieve a working install of TCL that satisfies my needs, and I don't care much for investing any further time into explaining or justifying my choices. Time is money and I got work to do...bye bye. :)
-
I've added all the listed deps (including expat2.tcz) and now the system boots fast into Xwindows, gets the blue screen with TC logo...but NO ICONS and a frozen mouse pointer in the center of the screen. It stays frozen that way.
CTRL-BACKSPACE got me to a console prompt...I ran 'sudo ldconfig' (did not know what else to do) and restarted Xorg with 'startx." Same result as before.
I have, on this particular computer, an ATI Rage 128 Pro video card. I looked into /usr/local/lib/X11/modules/drivers and the ati_drv.so and r128_drv.so drivers for the card are right in there.
There's a parameter /etc/sysconfig/Xserver that is used by tc to signal if Xvesa or Xorg is being used - perhaps in your scatter install this parameter was not set?
It is also possible that you need an xorg.conf to properly configure your graphics card rather than relying on the automatic configuration.
-
There's a parameter /etc/sysconfig/Xserver that is used by tc to signal if Xvesa or Xorg is being used - perhaps in your scatter install this parameter was not set?
I did set it manually, as I wrote earlier at reply #32:
Entering 'startx' gets the following error message:
cat: can't open '/etc/sysconfig/Xserver': No such file or directory
So, I added a file named Xserver to /etc/sysconfig with "Xorg" written in it and rebooted the system.
I also looked into /home/tc/.xsession and its first line shows it was properly set:
/usr/local/bin/Xorg -nolisten tcp &
It is also possible that you need an xorg.conf to properly configure your graphics card rather than relying on the automatic configuration.
I'll have to look into that.... Thanks.
-
@Juanito
I looked into /var/log/Xorg.0.log and found that Xorg's automatic configuration was indeed working just fine with my card. But then it hit me that I was using a modularized kernel I had built specifically for my old laptop which did not include the video module for the card on the system I was testing all this with...I'm very embarrassed to say :-[ . So, I promptly put in a more adequate modularized kernel and now, with the right kernel module for the card, TC (or more precisely, MC + Xorg) booted up with a working mouse pointer (which didn't have before, with the missing kernel module), but still no icons. Looked in /etc/sysconfig and - of course! - no icon file in there (due to the scatter mode install). So, all I had to do at this point was to create an /etc/sysconfig/icon file with text "wbar" and - voila'! - now Xorg works perfectly fine on this system. ;D
Scatter mode as you might say is perhaps the hard way to go about it, but let me tell you, it's the only way to to look under the hood and really learn how the system works...and there's that great feeling of exultation when you do and are able to overcome little obstacles, one by one. :) Very much worth the effort, IMO. I'm pretty sure you can relate to it.
So, all I have to do now is to recreate those changes listed at reply # 27 to achieve the end result I was aiming for. Let's see how it goes... The more I learn about TCL, the more fascinating and elegant I find it to be...
-
For those who have been following this thread....after delving (a whole lot) into the intricacies of Xorg I've come to realize how everything that was downloaded from TCL.com is geared (and rightly so) toward the TC philosophy. I've concluded that it would be much easier for me to build a small system from scratch than try and tweak tinycore into something it wasn't designed to be...so, that's what I'm now going to start working on - my little high-security linux from scratch project.
Many thanks to all those who have made an effort to answer my questions here...it has been an invaluable learning experience and I'm thankful for it.
-
So if I set a password for tc, make it permanent, and open the telnet port to the net with a telnet server running, there is no other user with a null password that can log in? Is that correct?
I set a password with passwd, then added these lines to /opt/filetool.lst
etc/passwd
etc/shadow
etc/group
etc/gshadow
and then issued filetool.sh -b
Am I good to go to open up the telnet port to the world now after a reboot? No other accounts with null or default install passwords that need changing?
Also... I can't find issue.net to change the login prompt blurb ( "Linux 3.0.21-tinycore" ) which tells the world it's a tinycore server (I would prefer to leave someone trying to break in, in the dark as to what kind of flavor of linux system it is).
Yes, I know telnet is not encrypted and I should use SSH, and have used SSH, but I do not want to use SSH. Unless SSH has minimal overhead... I have only 110mb of RAM and most of that is taken by Apache. The main PITA of SSH is it is not on any linux or windows or freaky old system by default... whereas you can almost always find a telnet client installed.
-
Do you have any motd file in the etc directory ?
cat /etc/motd
-
I edited /etc/motd yesterday, it didn't seem to do anything, even after I logged in. From what I remember, motd is spit out right after you sucessfully login, not before you login (and was used back in the day to display System News from the sys admin)
A google search told me the loging blurb was stored in a file called issue.net. For some reason, my login prompt also has a smilie face appended to the front of it as well? I think the smilie is probably the last character in issue.net, because it doesn't repeat if you press return. Not really a big thing.... :
Linux 3.0.21-tinycore (10.0.1.100) (pts/0)
☺box login:
-
Hi mrstarr
I edited /etc/motd yesterday, it didn't seem to do anything, even after I logged in. ...
Did you back it up and reboot after editing it?
-
IIRC editing /etc/motd needs remastering core.gz .
-
Hi Misalf
Not according to this:
http://forum.tinycorelinux.net/index.php/topic,17255.msg103574.html#msg103574
-
Then IDRC.
-
How do you update apache webserver on microcore?
My install is 10+ years old and some bug is being exploited by hackers that is filling up my router with open socket connections to apache running on my mc/tc webserver box that never get released.
I've had to close the open port forwarding to port 80 on my mc/tc webserver box (effectively shutting down my webserver) as these unreleased connections to port 80 will eventually fill up and overwhelm my router connections table and basically bring my entire home network to a screeching halt.
This is a new thing. Up until now apache has been running like a champ on tc for the last 10 years on a 400mghz thin client fanless box with only 110mb of RAM
I ran tce-update from the command line and all apps report up to date... but uh... probably not.
"version" from command line reports I'm running TC version 4.5.1 and in my extensions folder I'm running apache2
How do I update to the latest version of Apache? An "ab" search for "apache" only turns up apache2, not apache24 or anything else...
-
Hi mrstarr
If you want an updated version (2.4.33) of Apache I think you'll need to upgrade to TC version 9.