Multi-user system?

[florian]

Creating a empty extension with a startup script is a good trick!
I created myself a noautologin.tce as per your instructions! Works great! 

No more need to remaster for a multi user system!
I think this super tiny extension is well worth submitting to the repo (or alternatively Robert/TeamTC, what about a 'noautologin' boot option in TC2.3?)

ps: one minor sugestion if you submit your extension to the repo: maybe you just need usr/local/tce.installed/noautologin (aka write the updated /root/.profile from a here document included in this file). Removing root/.profile.noautologin from the extension might play better with whatever extension auditing mechanism (http://forum.tinycorelinux.net/index.php?topic=2475.0) may be added to TC.

[mikshaw]

TC, as I see it, is no system to be using in "large organizations".  Maybe I'm wrong, but the behavior of TC, and DSL before it, is great for personal use only.  There are features in TC that provide easy access to the system which would be considered security problems in a large company situation.  I would not recommend TC as it is today for a secure business OS unless you are willing to put in the effort to make some fundamental changes to the system.

[danielibarnes]

maybe you just need usr/local/tce.installed/noautologin

In that case, the usr/local/tce.installed/noautologin file would consist of:

mv /root/.profile /root/.profile.orig
cat <<EOF > /root/.profile
if [ -e /root/.profile.orig ]; then
cp /etc/inittab-save /etc/inittab
kill -SIGHUP 1
mv /root/.profile.orig /root/.profile
exit
fi
EOF

In principle, extensions are an extension to the core system. Any extension which only modifies the core system to add a feature may not fit in, or does it? I think the TC developers will discuss this and let us know. They have been very responsive to my feature requests in the past.

[roberts]

It would appear that more would want this option than I would have thought.

The TC developers could modify the stock /root/.profile to detect a boot parameter and execute logic that effects the same changes.

No need for an extension. Will investigate for 2.3. Thanks for your suggestion.

[bigpcman]

Does auto login  have anything to do with causing the unexpected (at least for me) behavior that occurs when starting  a dropbear ssh session with a tc system that has no active users and is "sitting" at the login prompt.  The local tc system brings up the tc user desktop upon receiving the dropbear connection request. The  remote dropbear  session then stalls waiting for something and displays:

Code: [Select]

login as: tc

Secure login powered by Dropbear SSH server.
tc@192.168.0.105's password:
Could not init font path element /usr/lib/X11/fonts/TTF/, removing from list!
Could not init font path element /usr/lib/X11/fonts/Speedo/, removing from list!
Could not init font path element /usr/lib/X11/fonts/Type1/, removing from list!
Could not init font path element /usr/lib/X11/fonts/CID/, removing from list!
Could not init font path element /usr/lib/X11/fonts/100dpi/, removing from list!
Could not init font path element /usr/lib/X11/fonts/TTF/, removing from list!
Could not init font path element /usr/lib/X11/fonts/Speedo/, removing from list!
Could not init font path element /usr/lib/X11/fonts/Type1/, removing from list!
Could not init font path element /usr/lib/X11/fonts/CID/, removing from list!
Could not init font path element /usr/lib/X11/fonts/100dpi/, removing from list!
^CX server terminated by an interrupt signal.

tc@box:~$
It takes a "cnt C" to bring back the remote prompt which then terminates the local tc user session.

[roberts]

Try booting TC/MCwith the added boot code of text.
If we were using the full openssh I could test for SSH_CONNECTION but I don't see that dropbear supports this, so the text work-around should do it.

[bigpcman]

TC, as I see it, is no system to be using in "large organizations".  Maybe I'm wrong, but the behavior of TC, and DSL before it, is great for personal use only.  There are features in TC that provide easy access to the system which would be considered security problems in a large company situation.  I would not recommend TC as it is today for a secure business OS unless you are willing to put in the effort to make some fundamental changes to the system.

and

From Robert - It would appear that more would want this option than I would have thought.
Quote
The TC developers could modify the stock /root/.profile to detect a boot parameter and execute logic that effects the same changes.
No need for an extension. Will investigate for 2.3. Thanks for your suggestion.

My humble interpretation of the theme surrounding the "auto login"  discussion is that it is not  simply about "auto login" but is indeed about "security". It could be that  "personal use only" is an outdated concept that only exists if you are locked in a room by yourself using an encrypted communication system.  Perhaps this subject deserves more general discussion rather than taking the position it's not practical or can't be done in Tinycore. Maybe if we all new what exactly had to be done a "security" boot code could be created and the supporting code developed by the community. By no means am I an expert or qualified to advise the Tinycore community about anything but as a start here's what the "security" boot code might do:

1. Make sure passwords are established
2. No auto-login on boot
3. Change sudo to not allow root actions or to some other predefined set of rules
4. Require root for installing system extensions
5. Change permissions where necessary

[danielibarnes]

A "security" boot parameter is a bad idea, because it's behavior would be subject to change from version to version. This is not desirable for a boot parameter.

Instead, a wiki entry containing helpful tips and scripts to "harden" Tiny Core is the best approach.

[lucky13]

1. Make sure passwords are established
2. No auto-login on boot
3. Change sudo to not allow root actions or to some other predefined set of rules
4. Require root for installing system extensions
5. Change permissions where necessary

1-2: Persistent /etc boot option (maybe option to encrypt it)? Not sure I really like the idea of going that far but it's probably easier and more customizable than having myriad scripts to manage certain boot/login options since TC is supposed to be usable as a live CD, from USB, etc. With too much convenience comes too much danger; with too much security comes too much hassle.

3: You can already do that via remaster or filetool, can't you? I've never liked the wide-open sudo but when you consider how portable/nomadic this is intended to be you have to weigh these things and decide how you roll and if this fits in with your tolerance for trouble (if it's THAT important, encrypt it). Anyone else can pretty much pop in some live CD and mount your partitions and get your data anyway.

4: Not sure I see practical reasons for this since extensions are intended to be modular rather than permanent.

Not sure what you mean by 5. I've encountered enough permissions problems running with user= cheatcode that I'm about to stop it. Sometimes it's easier to just go with the flow.

(edited to renumber and to reduce confusion)

[tclfan]

A "security" boot parameter is a bad idea, because it's behavior would be subject to change from version to version. This is not desirable for a boot parameter.
Instead, a wiki entry containing helpful tips and scripts to "harden" Tiny Core is the best approach.

If I can voice my opinion from end-user perspective, secure Tinycore, which means with proper user entitlements and not automatic inheriting root privileges through sudo is very important and should be default, rather than special boot option. It is OK to automatically log in as user, but system changes, including installation of extensions should require root privileges, therefore root password at least.
The way it is implemented now it is certainly far better than running as root. For this reason alone systems running as root such as Puppy are not acceptable for any serious use, but only for emergency recovery tasks.
One small change I would ask on the way is to require root password on sudo (I think SliTaz does this, not speaking of fat ones, like Ubuntu).
However the ultimate goal I see is to make it eventually multi-user by default. Even for a single user, a standard security is better than half-way security. Although TC is small today and meant for a single user, it is designed with modular architecture after all. This means one should be able to compose a system to his requirements from components on the base of TC core, including fully functional multi-user desktop systems. I would rather such core limitations not stand in the way of this possibility...
Just my two cents from user perspective...

[lucky13]

...proper user entitlements and not automatic inheriting root privileges through sudo is very important and should be default, rather than special boot option...

How is this different from any other live CD-based system including installable ones like Ubuntu? Both boot from CD with wide-open sudo powers from that environment. What am I missing in this argument since TC isn't Ubuntu and isn't installed similarly? Would this default behavior exist on CD, USB, etc., and could it be overridden via adding a cheatcode like "2" to a GRUB menu entry so anyone could log in as root anyway? Or even add in failsafe (root) GRUB boot option like Ubuntu has by default?

It is OK to automatically log in as user, but system changes, including installation of extensions should require root privileges, therefore root password at least.

The system is read-only and modular. If someone installs Opera and you only wanted dillo, just delete the package from tce/optional or wherever. You control what persists even in cases where you have to do it retroactively. The most important persistent data on your drive wold be settings in your own /home which can be encrypted en masse or singly via gpg.

However the ultimate goal I see is to make it eventually multi-user by default. Even for a single user, a standard security is better than half-way security.

It can already be run multi-user. My default GRUB entry is my real name (using the name= cheatcode) but I also have entries which get me to the totally "raw" state of the ISO/base. I could add one for any other user. I could also set up separate partitions so we don't have to share the same tce= or local= if necessary, so mine is on sda3 and hers is on sda5. Even if you share partitions and she puts stuff on  there you don't want, boot with "base" and "norestore" and un-do her stuff. What I want protected is encrypted, not merely behind a password which is no obstacle for anyone competent enough to boot a CD and mount other drives.

Although TC is small today and meant for a single user, it is designed with modular architecture after all. This means one should be able to compose a system to his requirements from components on the base of TC core, including fully functional multi-user desktop systems. I would rather such core limitations not stand in the way of this possibility...
Just my two cents from user perspective...

One can already compose a system to one's requirements, and one can remaster if there's more one thinks needs to be done. How is ultimate flexibility a limitation?

[lucky13]

Or if the current options aren't acceptable/desirable and persistent /etc is too much, how about a user profile option? Or just expand the user cheatcode so that it requires a password which is encrypted in persistent /opt and then uses /home/user and other existing variables so your own unique system state -- with your selection of default extensions and options -- remains unaffected by anyone else. And then the base system is entirely unaffected by those who insist on setting this up in such a manner. That would leverage what's already available, which works for a lot of people.

You'd have to reboot to change users. Boot time on my Aspire One is a few seconds and hardly longer than it would take to log in and out of a user account.

Just looking for some kind of compromise that can work for the most people without turning this into something too hacky.

[tclfan]

I am not saying TC LiveCd is different in this respect from Ubuntu LiveCD.
What I am trying to say many of LiveCds out there are based on a common concept that LiveCD is only for personal use, and therefore do not include security functions or multi-user functionality. They have their purpose too - such as recovery tools... or experimenting.
However having in mind wider perspective of normal use as desktop, such as 'diskless workstations' in multiuser environment, requires each user to authenticate to the common security infrastructure, e.g. Active Directory, so access and privileges are established.
Perhaps it can be made multiuser now, as you accomplished, but a pure advantage would be if it is architected by default, so it can be used to build wide range of systems to requirements, including security.

[danielibarnes]

What a lively discussion!

However the ultimate goal I see is to make it eventually multi-user by default.

Robert may choose weigh in, but I believe that is not his ultimate goal. As you work with TC, you realize that its purpose is to be flexible enough to enable everyone who uses it to reach their own individual goals. As useful as it may be to the average user, having firefox bundled with your distro can be an impediment if your goal is to create a router that fits on a 16MB flash disk. The fact that the noautologin feature can be added via extension without remastering is a testament to its flexibility. It enables one to achieve the "multi-user" goal even though it is designed for single-user operation. I expect it is possible to create extensions for NIS or LDAP to achieve even more.

Modifying default behavior is something which must be carefully examined so that the goals of other users are not threatened. In this case, I know several users which depend on the "autologin" behavior. It is far more friendly to non-technical users and is especially useful for kiosks. Changing the default behavior would mean those users would now be the ones who have to modify the system (or use a boot parameter similar to "single" in conventional distros) to achieve their goals.

While I am definitely a user of the "noautologin" feature (some of my virtual appliance servers deny login entirely -- local or remote), and I support making it an option, I believe it would be unfair to make it the default.

[roberts]

Daniel, is correct in his statments. It is not my goal to target TC to be that specific.
I might implement some suggestions, but likely not all of them will be bundled up. It is up to you to deploy our Core offerings as your needs determine. A Wiki page about hardening is welcomed.
Many live Linux environments use sudo. So shall it remain. My goal is to keep TC (Fltk GUI) and MC (CLI) as small as practical in a traditional live Linux enviroment offering more flexibility than most by way of extensions.