Tag Archive | permissions

Top 10 Linux FUD Patterns, Part 5

Linux FUD Pattern #5: Linux is not secure

There are some out there who would like for you to believe that Linux is unsafe. What better way to instill fear than to form doubt in your mind about a system’s abilities to protect your data?

A reason for the supposed lack of security often cited in FUD is the origin and maintenance of Linux in the “hacker” community. The term “hacker” has evolved from a term of endearment to one associated almost exclusively with cybercrime. To say that Linux was created and is supported by hackers gives the impression that the OS and its related applications are riddled with built-in security holes, backdoors for gaining system access, spyware for purposes of identity theft, hidden network tools that help intruders cover their footprints as they travel from machine to machine through cyberspace, and any other sort of malicious software for various and sundry purposes. To “hack” no longer means to “tinker” or to “fiddle with”, but to “break into” and “cause harm”. The term may conjure mental images of a scene from a horror movie, an evil man with an axe about to hack his way through the door to the house protected by the dark of night. Such is the imagery used to spawn fear.

Let’s examine Linux security by answering two questions. Do security components exist? And, can they be trusted?

The components required to make a system secure depends on many factors, because different systems are used in different ways by different people. Moreover, a weakness in a system’s security may be mitigated by strengths in some other compensating controls. There are some basic options that are commonly used to secure systems, all of which are available on Linux.

Password protected login is the hallmark form of authentication. It is easy to implement, easy to use, can be highly effective, doesn’t require additional/expensive hardware and the expectations and conventions surrounding it are already present in modern culture. Sure, there are more advanced biometric devices such as palm readers and retina scanners, but the relative cost in money and effort of implementing these safeguards for the average home user and for most business desktops is prohibitively high. There are two aspects to password security: the strength of the password itself, and the authentication scheme behind it. Password strength is the responsibility of the user, not the OS. Most Linux distros either require password protection or at least have it enabled by default. Usually, the passwords are protected on the local system by shadowing and various schemes such as Kerberos can be used to protect the transmission of login information over a network.

Related to password authentication is the file system permissions granted to users once they’ve logged in. Linux and Unix use file-based permissions, denoting how the owner, members of the owner’s primary work group and the “world” of users on the system can interact with each file or directory. Privileges do not cascade as they do with other operating systems that use Access Control Lists.

Network security is a broad topic encompassing the combined abilities of the OS, applications, network devices, administrators and users to detect and/or prevent a breach attempted across a network connection. A basic way to accomplish this is to disallow certain types of messages from reaching the computer; this function is usually performed by a firewall server or program that monitors network traffic and filters communications based on predefined rules. Every computer that communicates over the Internet uses the TCP protocol, which allows for approximately 65,000 possible “ports”. These ports are similar to radio stations or TV channels; each application that needs to communicate does so using one port. Ports that are not used by an application but are still available for use (“open”) can be exploited. Port scans are a good way to determine if a system has any open ports that are not being used. Firewall capabilities are built into the Linux Kernel and several good front-end packages are available for configuration, monitoring and reporting purposes.

All of the safeguards discussed above constitute protection around the data. What about protection of the data? A data file can be encrypted thereby changing the contents to an encoded, unreadable format. The content is usually restored using a key or a password. E-mail can also be encrypted prior to transmission. GNU Privacy Guard (GPG) is a Pretty Good Privacy (PGP) compliant application that implements public key cryptography on multiple OS platforms, including Linux. Of course, constantly having to decrypt and encrypt every individual data file before and after use would be painful; instead, entire file systems can be encrypted by the system and several cryptographic file systems exist for Linux. It is also possible to create a loopback device, which is a file that can be mounted as an encrypted file system similar to the commercial product Cryptainer LE by Cypherix.

So, the components do exist. Now, the question remains, can these components be trusted?

FUDsters will argue that any security software for which the source code is freely available to the public is inherently not secure. This is based on the assumption that the source code will either reveal the secret functionality that makes the security software work or expose bugs in the security software itself that can be exploited as well.

First, if someone cannot open their source because they are afraid it may reveal secret functionality, then it wasn’t properly designed from the start. The worst-possible example of this is hardcoding passwords in programs, especially if they are scripts stored in clear text. Good security schemes, such as encryption, rely directly on information the user provides, and often make use of one-way functions.

Second, Open Source software is available for public scrutiny. If you cannot read and understand the code yourself, rest assured that there are many folks out there that can and do. Why? Because many businesses do actually use Open Source software and have everything to lose if they don’t test it out first. That being said, I consider many corporate “testimonials” sponsoring one OS or another based on security or other factors to be FUD, mainly because they often appear in paid advertisements and seldom reveal the details of tests performed to lead to such conclusions. Independent certification and research performed by government or other nonprofit entities are usually the most objective and reliable.

Aside from learning the code, another way to test an application’s security strength or to see if it transmits private data is to watch (or “sniff”) the port on which it communicates using a network monitoring tool. Such data may be encrypted, but the (data) size and timing of requests made by the client software should be consistent and reasonable. This is a technical task, but a bit easier than learning how the code works. Just remember, sniffing outside of your own network may be considered illegal.

Finally, there are many Linux opponents that would jump at the chance to expose real security weaknesses in Linux and its applications. These are often vendors of competing software and have both the money and channels to make themselves heard. When such a claim appears on the Web, look for specific details about the vulnerability. If there are none, it may be FUD. Also, check the software website to see if the vulnerability has been acknowledged or refuted as well as any status on its repair. Never take such claims at face value.

Here’s a few tips to remember to help protect yourself.

Any security expert worth his salt will tell you that physical security is the most important aspect of system security. If physical access to a computer is available, then it is usually just a matter of time before the system will be compromised, regardless of operating system. Obviously, the probability of such breaches skyrockets for laptop users, especially when so few (based on my own observations) choose to utilize even the most primitive of safeguards, cable locks. Also, I’ve not seen any major headlines on this so far, but Live CDs, as wonderfully useful as they can be, are ginormous threats to the security if physical access is available. This is because most Live CDs provide superuser access to a system and all of its devices. It is best to keep computers under lock & key whenever possible.

One of my friends from university used to work in an engineering lab on campus. He had set up a Linux box on the network, with full consent of the administrators of course. But one of the the permanent staff members approached him one day, asking how he managed to cloak his machine from the nightly SATAN network scans. The answer was simple! He turned the machine off before he left each day! Turning a machine off or at least disconnecting it from the Internet when not in use will deprive the would-be attacker the time needed to successfully break in using a brute force attack.

And, as always, be careful what you download. There is always a chance that someone will write spyware or malware for Linux. Stick with applications that have large communities and good reputations if you can. Search the Internet for evidence that an app may not be secure before downloading it. To quote the the Gipper, “trust, but verify”.

Cheers!
-Brandon

<< Go To Part 4 Go To Part 6 >>

Yo! Linux Newbies! You Don’t Need an Antivirus!

No VirusRead EVERY WORD of this article by Joe Barr including its very helpful user comments and burn it in your brain: you are not using a Microsoft product when using Linux, therefore you will not get a virus. This is possible because Linux was built CORRECTLY and because of its implementation of permissions.

“Microsoft designed Windows to enable outsiders to execute software on your system. The company justifies that design by saying it enriches the user experience if a Web site can do ‘cool’ things on your desktop. It should be clear by now that the only people being enriched by that design decision are those who make a buck providing additional security or repairing the damage to systems caused by it.”

Get out of the Microsoft mentality.

Adventures in a New Ubuntu 6.10 Clean Install: Day 3

Day 3

How to Mount a FAT32 Drive/Partition with Read and Write Access for All Users

The next step I tackled in my sexy, shiny, and sultry Ubuntu 6.10 was to mount my FAT32 Data Partition so I can read and write to it and access my previous Ubuntu 6.06.1 backups, along with all my other data, of course.

Since the Disks applet (I think that’s what it was called in 6.06.1) is no longer available in Gnome because it is unmaintained, I would have to manually edit my /etc/fstab file. For those who don’t know, this file mounts the partitions, CD/DVD Roms, floppies, etc, of your file system.

Before you edit this file, you should do a backup of it:

sudo cp /etc/fstab /etc/fstab_backup

Here is what my fstab file looks like:

# /etc/fstab: static file system information.
#
#
proc /proc proc defaults 0 0
# /dev/sda1
UUID=21b32fac-8d97-4ee0-89e7-bbf3dc146ec8 / ext3 defaults,errors=remount-ro 0 1
# /dev/sda5
UUID=fd07dad2-18d3-4ad2-9a19-b9801d056927 none swap sw 0 0
/dev/hdd /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/hdc /media/cdrom1 udf,iso9660 user,noauto 0 0
/dev/ /media/floppy0 auto rw,user,noauto 0 0

I figured that mounting my FAT32 Data Partition would be easily done by adding the following line at the end of my /etc/fstab file:

/dev/hda5 /data vfat iocharset=utf8,umask=000 0 0

…and then do a: sudo mount -a #Mounts everything in fstab

It worked, but the root of my My Documents folder on that partition wasn’t writable. Some other folders at the root level were writable and others weren’t. Also, some folders within My Documents were writable and some weren’t, like My Music, My Pictures, and others. Seemed like the “Windows-related” folders weren’t writable. But folders within those folders were writable.

It’s odd.

I figured I could just do a sudo chown -hR leonivek:leonivek /data but I would only get an “Operation not permitted” error.

After searching on the Ubuntu Forums, this post explained that I would still need to change the actual permissions of that mount point. To do so, I had to do this:

sudo chmod a+w -R /data

Bingo! Now everything is accessible — read and write — for all users.

If you need some help with your fstab and mounting drives, I recommend reading the following pages: