Multi-user system?

[lucky13]

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.

[bigpcman]

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.

[tclfan]

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.

[jpeters]

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#

[danielibarnes]

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. :)

[jpeters]

Just adding "kill -SIGHUP -1" to /opt/bootlocal.sh also seems to work;  ctr-alt backspace takes you to login. 

[roberts]

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.

[jpeters]

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.

[danielibarnes]

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.

[bigpcman]

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.