Is TCLs Cloud Mode computing really secure ?

[Pats]

While discussing abt TCL in our group, the natural Question was raised abt Security aspect of TCLs cloud mode !

1) Is TCLs cloud mode really secure as far as private data of the user is concerned ?
2) What security can be provided to the user for production level setup of any enterprise ?
3) Has anybody exploited the possible loop-holes in TCL - perticularly in Cloud Computing mode ?

Experts may provide some clues on the subject.
Thanks !

~ Pats

[Guy]

No computer connected to the internet can be guaranteed to be totally secure.

I suggest installing Tiny Core, not using cloud mode on a long term basis.

Use Iptables and basic firewall.
To start a basic firewall each time Tiny Core is started, add
sudo /usr/local/sbin/basic-firewall
to /opt/bootlocal.sh.

If you do this, Tiny Core is in stealth mode. Anyone trying random IP addresses will not get a response from Tiny Core, so they won't know it is there.

Anything sent to your computer which you have not requested, by clicking on something, will be dropped. It won't be allowed into your computer.

Another big advantage of Tiny Core is the frugal installation. If something was to go wrong, when you turn off the computer and restart it, the problem would be rectified.

Linux is inherently much more secure than Windows to begin with.

[Pats]

No computer connected to the internet can be guaranteed to be totally secure.
I suggest installing Tiny Core, not using cloud mode on a long term basis

VVery Important point , you said !

To start a basic firewall each time Tiny Core is started, add
sudo /usr/local/sbin/basic-firewall
to /opt/bootlocal.sh.

Thanks !

If you do this, Tiny Core is in stealth mode.

I hope none of the tricks explained here :
http://linuxreviews.org/news/2004/06/11_kernel_crash/

apply to TCL !

Another big advantage of Tiny Core is the frugal installation. If something was to go wrong, when you turn off the computer and restart it, the problem would be rectified.

Can the persistant direcrory be exploited by hackers ?

Linux is inherently much more secure than Windows to begin with.

That is for sure !

Thanks !
~ Pats

[Guy]

I hope none of the tricks explained here :

I don't know about the specifics of that info.

Because of the frugal installation, if Tiny Core works the first time, it will work every time.  It has huge advantages over conventionally installed operating systems, which may have files corrupted as a result of malfunctions, malware, user error, or just because the operating system is imperfect.

Can the persistant directory be exploited by hackers ?

It is extremely unlikely that hackers will get into Tiny Core with a firewall. If they did, no one can predict what they might do.

[Pats]

Will it be timely and convinient - if TCL is ported with the basic firewall already built in the distribution ISO - considering TCLs cloud mode AppBrowser nature?
And then a shell script to dis-able it , if somebody not want it ?

If someone forget to start the fire-wall during live boot session or a boot code to start the FW at start-up ?
 ~ Pats

[curaga]

Regular cloud mode runs no servers, so how could an attacker connect to you. Servers anyway should be run as some other user (usually "nobody"), that doesn't have sudo rights.

OTOH, if someone has control of your DNS, they can point ibiblio to their comp.

[Guy]

I said above, it is better to install Tiny Core and set up a firewall.

However, if people choose to regularly run Tiny Core from the CD and use cloud mode, that is also very secure.

There is nothing on the CD which is of any value to hackers.

Don't have anything of value to hackers on your hard drive, such as bank account details.

Don't have your hard drive mounted, so they cant access it anyway.

If run like this, cloud mode is very secure.

[lucky13]

Sorry for venturing off topic...

Linux is inherently much more secure than Windows to begin with.

Ipse dixit. Linux enjoys security through obscurity. Windows' 95% market share makes it a more lucrative target than something that's greatest market penetration remains servers (where it's also quite vulnerable to compromise). No system is "inherently secure," particularly since users don't always keep their systems patched even if distros and upstream project leaders are on the ball; it also doesn't help that most users -- server or workstation -- exercise little restraint, common sense, or caution when using them. Also, there's this madness affecting most distros to use the most recently released version of any software rather than patch only for bugs and/or security; most "testing" has nothing to do with auditing/testing and more to do with making sure something doesn't repeatedly segfault or cause issues with other packages.

http://blogs.zdnet.com/security/?p=268
http://blogs.computerworld.com/14723/no_more_linux_security_bragging_botnet_discovery_worry
http://lucky13linux.wordpress.com/2009/08/23/linux-security-hole-goes-back-eight-years/
etc.

To get back to the topic, any persistent (rw) partition in TCL can be compromised by attack. So while the base can be "reset" via reboot, persistent config files can be overwritten and any data stored on media connected to your computer could be read, etc.

Per the second question about enterprise/production use, I wouldn't ever recommend TCL for such use without some deliberate changes. Those would start with tightening sudo rules and requiring a login rather than booting to a prompt or with an X desktop. I'd also ditch cheatcodes (norestore, base, etc.) that could be used to override my changes at least by local attack.

[Pats]

Servers anyway should be run as some other user (usually "nobody"), that doesn't have sudo rights.

I think, even for Stand-aone server, the well-known shell script by nixCraft is famous - which

goes something like this:
....
....
IPT="/sbin/iptables"
SPAMLIST="blockedip"
SPAMDROPMSG="BLOCKED IP DROP"
 
echo "Starting IPv4 Wall..."
$IPT -F
$IPT -X
$IPT -t nat -F
$IPT -t nat -X
$IPT -t mangle -F
$IPT -t mangle -X
modprobe ip_conntrack
 
[ -f /root/scripts/blocked.ips.txt ] && BADIPS=$(egrep -v -E "^#|^$"

/root/scripts/blocked.ips.txt)
 
PUB_IF="eth0"
 
#unlimited
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
 
# DROP all incomming traffic
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP
...
...
( incomplete - given just for example.. )

Don't have anything of value to hackers on your hard drive, such as bank account details.
Don't have your hard drive mounted, so they cant access it anyway.

any persistent (rw) partition in TCL can be compromised by attack. So while the base can be "reset" via reboot, persistent config files can be overwritten and any data stored on media connected to your computer could be read, etc.

In short, TCL is currently of no use for any production/critical level installations - if we should not mount even our HDD - then we should be just happy with TCLs experimental value !

I'd also ditch cheatcodes (norestore, base, etc.) that could be used to override my changes at least by local attack..

Very Important & clever thinking - I think , but then w/o these chit-codes TCL may be paralysed -  is not it ?

The Q is - is TCL Team going to keep TCL Diskless status for-ever ?
TCLs 2nd anniversary is very near (12/1) - Should we - the interested users demand more from TCL ? 

~ Pats

[gerald_clark]

Demand?
Whose project is this anyway?

[Jason W]

A few demand more user friendliness, another few demand more security.  You cannot please everyone with a default offering. 

If you want to run a firewall, it is only a couple of steps.  If you want to lock your machine further like for an always-on server, you can do that too.  Remove sudo and disable on demand package installation?  Go for it.  The whole point of TC is that is up to you what kind of system you want.  The team and contributors try to give you the tools and packages to enable you to get what you want.

It is normally advised security-wise to have installed and running only what you need.  TC is ideal on that point.  You have to have a service installed and running for it to be compromised.  And while larger distros often have more of a security structure, their default install also may be running almost a dozen services that a newer user doesn't even know exist. 

Like Burger King, one of the TC concepts is "have it your way".

[thane]

I've got iptables/firewall installed, but I'm not sure I really need it. About all I do is web surfing. Also I'm behind a router although it doesn't have any firewall as far as I know.

[Jason W]

I have a TC firewall/dhcp server installed on an old box that I have my network behind.  Mainly to give me a dhcp server when my DSL (internect connection) router is down, which sometimes happens in bad weather.  I have one TC machine that has nfs and ssh servers running that is my file server, so I like to have a firewall between it and the web. 

As for security, cloud mode is pretty good if your intent to to do some banking or other sensitive operations, stay on only as long as needed, and then reboot.  The security there would be more web browser related than firewall related anyway.

One saying I heard is that practicing security is more important than patching for security.  Ideally, both should occur.  If you practice security but your apps are a little behind in receiving the latest security patches, there is a chance that you can be compromised.  But if you have all the latest patches applied but don't practice security, you are worse off than in the former case.  If you run the latest Firefox or Opera but you leave your desk in a public setting while logged in to your bank account, guess what can happen.  Similar for using weak passwords.

[robc]

Also if you are concerned about security you should disable icmp request reponses and uptime detection.

[lucky13]

In short, TCL is currently of no use for any production/critical level installations - if we should not mount even our HDD - then we should be just happy with TCLs experimental value !

Note I wrote "connected" and not "mounted." Mounting is no problem if anyone gets in as users tc or root, whether local or remote. The only safe media is disconnected.

Experimental? It's fine for nomadic/portable use. I only use TinyCore from USB even though I still have it installed on my Aspire One's hard drive (Liinux has proven utterly unusable with Atheros time outs and I grew wary of trying to sort out if it was with the Atheros drivers, WPA, or the card itself -- which functions flawlessly under XP so I only use XP). It's quite fine for a portable system. If you want enterprise-level Linux, you need something which is branded and -- most importantly -- supported as such. That means SLED and RHEL (and its clones, e. g., Oracle Unbreakable Linux, Scientific Linux, CentOS, etc.). I'd include Debian since it isn't tied to a fixed release cycle and has a fairly length support cycle, but that's only relative to other distros that focus less on security/stability than bleeding edge release numbers. FWIW, I'm currently using Scientific on my "new" laptop and also my desktop and am quite happy with it even though it's not bleeding edge (it's well-patched, though, with SL's security patches coming <= 48 hours after RH's).

Very Important & clever thinking - I think , but then w/o these chit-codes TCL may be paralysed -  is not it ?

Thanks and I concur with your kind words. I like to think I'm very important and that my thinking is clever.

The answer to your question: No. The user should always have the final say in how it functions on his own hardware. The compromises I pointed out aren't "limitations" or vulnerabilities or necessarily bad. TCL's philosophy is to be portable and modular. Those are things a user can un-do on his own but are necessary compromises to allow users more control over how things work. The very things that make things easier for users -- things like "sudo su" and cheatcodes --  are also things that make it easier for others to affect your system.

I agree with Jason that other traditional on-disk distros offer their own set of compromises by offering more security infrastructure if you can live with additional default services. Those are typically compromises that *do* matter in an enterprise/production scenario and the trade off is worth it. The "tightest" default install I've encountered is NetBSD's which requires the admin/user to even start SSH (OpenBSD's default is to start SSH unless the user says no at install). Most Linux distros are going to start a variety of default services which must then be shut down if the admin/user doesn't want or need them. TCL takes an approach I like better: if you know you need a particular service (CUPS, SSH, httpd, etc.) you're likely to set it up yourself.

Should we - the interested users demand more from TCL ?

Only if you make your own demands on your own hardware; if you think its default options are unsuitable for your intended use(s), remaster it so that it is. This is one of the great things about something as flexible as TCL. There's an annoying problem that pops up with nearly every open source project which manifests itself by suggesting something like "I need or want it to behave like this so the developers should implement this ASAP." What works for everyone else never matters when this problem pops its ugly head. Make it work on  your own hardware or work with those who share your own peculiar needs, then offer your changes to others in the community.