Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: fladd on August 20, 2009, 08:27:25 PM
-
Hi there,
does TC support a usual multi-user system? If so, can everyone have its own persistent home?
Regards,
fladd
-
If you use the home= boot option, it will store all of them on there as /home is mounted there (assuming all user homes are /home/...)
-
http://forum.tinycorelinux.net/index.php?topic=836.0
-
FYI, the adduser/addgroup commands are available in the base
-
Someone correct me if I am wrong, but using this method, users can access each other's files.
If you use the cryptohome= option, it can be set up so users don't have access to each other's files.
You need a different partition for each encrypted home.
-
You can see files, but many of the apps won't work and you don't have root access to change permissions.
-
Guy: if you prefer a stricter setup, use chmod to get rid of the r/x permissions for g/o on the home directories
As for full access to specific files, it depends on the permissions on those.
-
if you prefer a stricter setup, use chmod to get rid of the r/x permissions for g/o on the home directories
This doesn't make the system completely secure, as people can still log in using other's names, and can have root access to other's files or to change permissions.
This is probably not the first priority as effort is being put in to develop other aspects of Tiny Core. But at some time in the future It think it will be a good idea to require passwords to log in, and for root access.
-
That's something different. If you don't trust your users with root access, don't give them such privileges. (thought you were referring to file permissions)
-
The way Tiny Core is at present, it is good for personal use.
In the future, as it becomes more developed, it could also be used for non-personal use. For example, on networks in large organizations.
In that situation, these issues will need to be addressed.
Tiny Core actually has advantages over mainstream operating systems.
Everyone is doing a great job. I understand it will take time for all that is needed to get to that stage.
-
The way Tiny Core is at present, it is good for personal use.
In the future, as it becomes more developed, it could also be used for non-personal use. For example, on networks in large organizations.
In that situation, these issues will need to be addressed.
Tiny Core actually has advantages over mainstream operating systems.
Everyone is doing a great job. I understand it will take time for all that is needed to get to that stage.
Most of the large organizations are using centralised user authenticantion. This is safe to expect it is MICROSOFT ACTIVE DIRECTORY. Integration of any LINUX system to AD is a pain actually. Without proper authentication and integration in a well maintaned corporate environment you can do nothing. No access to the net, no access to mails with EXCHANGE, ...
It works only if the infrastructure supports LINUX, but it is extra cost and risk, no centralized solution like in WINDOWS, ...
From the corporate IT perspective a live LINUX is a security risk which must avoided.
It is not about TC, it is about UNIX.
-
Well, I suppose the focus may not be what you want it to be, but currently the autologin can be changed with a relatively simple remaster.
Adding "regular" users/groups that do not have super-user privileges can be done without a remaster.
@bmarkus: that's some heavy assumptions there...
[This is getting a tad off-topic... will split if needed]
-
@bmarkus: that's some heavy assumptions there...
[This is getting a tad off-topic... will split if needed]
Well, large organizations were mentioned. Of course there are different practices. However I was working in large global corporate environment and know the issues, arguments and daily operational problems.
Anyhow, it is off topic here.
-
(perhaps deviating from the topic again)
Well, I suppose the focus may not be what you want it to be, but currently the autologin can be changed with a relatively simple remaster.
This makes me think that "How do I stop the auto login?" is a recurring question in this forum. First, I guess it deserves one entry in the FAQ. Second, although a remaster isn't hard, would it be possible/desirable/feasible to introduce a 'noautologin' boot code?
-
I tried this very thing. I discovered you cannot effect a change in /etc/inittab until after tc-config exits because it is run by init. Therefore there is no opportunity to prevent auto-login via this method unless you remaster. However, since extensions are processed before the autologin you have the opportunity to modify /root/.profile.
I created an extension that saves the current /root/.profile and replaces it with one which will:
1) Copy /etc/inittab-save over /etc/inittab (you may wish to copy a custom one or otherwise modify the original /etc/inittab)
2) Reload init (kill -SIGHUP 1)
3) Restore the original /root/.profile
4) Logout (via exit)
The autologin processes this new /root/.profile. It reloads the desired /etc/inittab and logs out. Thus, autologin never occurs more than once, and the user is never presented with a shell. The TC developers could modify the stock /root/.profile to detect a boot parameter and execute logic that effects the same changes.
With some other extensions to enable NIS, LDAP, or create local users, this can enable a conventional multi-user system. My extension contains two files:
usr/local/tce.installed/noautologin
mv /root/.profile /root/.profile.orig
mv /root/.profile.noautologin /root/.profile
root/.profile.noautologin
#!/bin/sh
if [ -e /root/.profile.orig ]; then
cp /etc/inittab-save /etc/inittab
kill -SIGHUP 1
mv /root/.profile.orig /root/.profile
exit
fi
-
Creating a empty extension with a startup script is a good trick!
I created myself a noautologin.tce as per your instructions! Works great! :D
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.
-
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.
-
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. :)
-
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.
-
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:
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.
-
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.
-
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
-
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.
-
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)
-
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...
-
...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?
-
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.
-
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.
-
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.
-
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.
-
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.
I think we're going to end up talking past each other if we don't get on the same page about definitions. For example, I don't equate enterprise-grade security needed in a multiuser environment with "normal use as desktop." I also don't see that as "wider perspective" -- it's a niche and aren't there enterprise distros with strict logging and maybe SE/AppArmor/GRSec better suited for such needs?
I'm not saying TC couldn't be molded into that kind of shape, I just don't see TC as a RHEL/SLED equivalent on which I'd run my office. At least not without the kind of reconfiguration required to make it suitable for that kind of environment. That should be left to an end user who wants that, not forced on every user by developers.
As others have pointed out already, turning TC into that by default would make things a pain in __ for a lot of people who don't need or want that. I like how TC is a blank slate. I like that it can be morphed without remastering or that it can be remastered if your own needs require that. If an existing option or series of options can be modified to get you closer to your multiuser goal, then great. But it shouldn't be done at the expense of the way many people are already using it.
-
Well now that was an interesting discussion!
Although I brought up the idea of a security boot code I too know that there are better solutions. By simply using two grub entries completely different tc/mc profiles can be automatically booted by adjusting the boot codes. For instance different tce directories can be specified as well as things like text mode and passwords.
Indeed the flexibility of the tc/mc system is a major advantage of this distro.
Since my use of mc is for an always on web server I am concerned about security, but it is unrelated to desktop use. For me things like ssh user sessions that can su to root are not a good idea. Sure I can fix this and I can install a firewall and configure strict iptable rules. But is that it. Am I done. I really don't know because I am not an expert to that level of detail.
I for one would greatly appreciate a tc/mc hardening wiki page and whatever else makes sense to help users secure their systems according to their needs.
-
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.
I do not disagree with any of this. By my saying that TC should be architected as multi-user by default does not mean to enforce it regardless of purpose of specific implementation. This is a modular architecture we are talking about after all, and different implementations will have different needs. E.g. it would be pointless to enforce multi-user security for embedded appliance, where not needed. All I was saying was that multiuser capability should be available in the base architecture by default, so it would be available for implementations where required, without complicated modification. And it would not be used where not required. This is the beauty of TC architecture after all that by selecting components and features, system can be molded different ways to requirements, according to the intended purpose.
I see there is hardly any difference of opinion here, except I see a significant value in having such capability available in the architecture vs. having to seriously customize in order to accomplish this.
To emphasize, I completely agree that TC should be flexible to accommodate different purpose implementations. If I was understood differently, I did not mean to create such impression.
-
Maybe a little off topic, but some more on shadow-utils passwords:
In multiuser environments it is very important to use shadow passwords (provided by the shadow-utils package). Doing so enhances the security of system authentication files. For this reason, the installation program enables shadow passwords by default.
The following lists the advantages pf shadow passwords have over the traditional way of storing passwords on UNIX-based systems:
*
Improves system security by moving encrypted password hashes from the world-readable /etc/passwd file to /etc/shadow, which is readable only by the root user.
*
Stores information about password aging.
*
Allows the use the /etc/login.defs file to enforce security policies.
https://listman.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s1-users-groups-shadow-utilities.html#
-
To emphasize, I completely agree that TC should be flexible to accommodate different purpose implementations. If I was understood differently, I did not mean to create such impression.
Sorry about that. We're definitely on the same page then. I think that two valuable concepts worth further discussion have sprung from this, though:
1) How to harden Tiny Core (including extensions) for improved security, and
2) How to modify Tiny Core to enable a multi-user mode of operation.
I think a Wiki page entry for each of these is a good idea. An extension would be helpful, but there are so many possible solutions that one extension could not address them all easily. A Wiki page would allow the user to pick and choose the security options and multi-user configuration that suited them best.
A few examples for #1
- Edit dropbear options to allow key authentication only
- If you need scp/sftp file transfer but not remote login, use scponly extension
- If you use one of the web server extensions, run it with chroot
- Tips for securing samba and nfs extensions
A few examples for #2
- Add /etc/passwd, /etc/group, and /etc/shadow to mydata.tgz
- Support NIS, LDAP via extension
- Prevent auto-login
I will look into this at my first opportunity. If anyone else is motivated, please start some pages. :)
-
Just adding "kill -SIGHUP -1" to /opt/bootlocal.sh also seems to work; ctr-alt backspace takes you to login.
-
Talking about being able to edit your grub boot options to circumvent noautologin...
Booting norestore would circumvent the /opt/bootlocal and autologin would occur.
If using an extension, booting with base would prevent loading, and autologin would occur.
That is why, prior to this discussion, it was suggested to make a remaster.
-
Talking about being able to edit your grub boot options to circumvent noautologin...
Booting norestore would circumvent the /opt/bootlocal and autologin would occur.
If using an extension, booting with base would prevent loading, and autologin would occur.
That is why, prior to this discussion, it was suggested to make a remaster.
That wouldn't stop someone from booting from their own disk. Security is all a matter of degree.
-
If you have access to the grub boot menu, there is no security. I use the "single" boot parameter on other distros when I need to reset the root password. When I create tiny core iso images, I disable the prompt in isolinux so there is no opportunity for modifying how it boots. This is more to prevent someone from booting up incorrectly than for security though.
-
To emphasize, I completely agree that TC should be flexible to accommodate different purpose implementations. If I was understood differently, I did not mean to create such impression.
Sorry about that. We're definitely on the same page then. I think that two valuable concepts worth further discussion have sprung from this, though:
1) How to harden Tiny Core (including extensions) for improved security, and
2) How to modify Tiny Core to enable a multi-user mode of operation.
I think a Wiki page entry for each of these is a good idea. An extension would be helpful, but there are so many possible solutions that one extension could not address them all easily. A Wiki page would allow the user to pick and choose the security options and multi-user configuration that suited them best.
A few examples for #1
- Edit dropbear options to allow key authentication only
- If you need scp/sftp file transfer but not remote login, use scponly extension
- If you use one of the web server extensions, run it with chroot
- Tips for securing samba and nfs extensions
A few examples for #2
- Add /etc/passwd, /etc/group, and /etc/shadow to mydata.tgz
- Support NIS, LDAP via extension
- Prevent auto-login
I will look into this at my first opportunity. If anyone else is motivated, please start some pages. :)
For both 1 and 2, I would like to see some advise as to how to force disk/ partition level commands to require a root password. Like mke2fs, fdisk or hdparm .. any command that can destroy a system with a single sudo command.