Rsync Backup System [4]: Linux File and Directory Security Using ACLs

As per our series on Rsync backups, we desire to use a different user from the one that owns the home directory in order to ensure they have only the permissions they need when logging in remotely. At this point whilst by default the backup user could access many things on the computer, there were some files that they received permission denied errors for.

Whilst there is a simple file and directory permission scheme built into Linux, the acl extensions are very worthwhile as they give a lot more control, especially with the all-important ability to have inheritable permissions on a parent folder. In this case we'd want to give the backup user read-only permissions on the home directory that are inherited by all subdirectories and files as they are created.

Getting ACL is pretty simple, firstly you need to install the acl package using apt. The second requirement is to see if a volume is mounted with acl support. Use a command called tune2fs -l /dev/xxx (part of e2fsprogs package) and look for "Default mount options". If it says acl in there then the volume will be mounted by default with ACLs enabled. If this is not a default then you'd want to go into the volume mount entry in /etc/fstab and you can add acl to the mount options there. In this case because in fstab I used "defaults" as the mount options, acl is automatically turned on at mount time. If I needed to specify acl then I could change the word "defaults" to "defaults,acl" in the fstab entry to enable ACLs.

ZFS also has its own (more extensive) ACL support which is not covered by this post as we are referring to the existing filesystems which are ext4 on the computers being backed up in this case. I am not planning to change the existing RAID arrays from MDADM to ZFS but it could be an interesting consideration for the future should a disk array be replaced in any system.

Now how to configure ACLs for our requirement? Commands used to set and get ACLs are setfacl and getfacl respectively. To set up read access for backupuser on /home/patrick we need to use a command that looks like this:

setfacl -dR -m u:backupuser:rx /home/patrick

If we then use a ls -l (or ls -al) command in /home/patrick we can see next to the standard permissions a + sign which tells us that ACLs are set. In this case I can see whilst all directories have ACLs set, the files that are in each directory are not set with ACLs. So I would need to run another command to set these:

setfacl -R -m u:backupuser:rx /home/patrick/* /home/patrick/.* /home/patrick/*.*

The two different commands are as follows:

The first one using 

-d setting the default ACL for each directory (the default ACL to be applied to any new file or directory)

-R operating recursively on all subdirectories

-m modifying the ACLs

u:backupuser:r is user backupuser granting read permission.

The second one is practically the same except there is no default applied because it is for existing files and the paths following it are the different filespecs to match. 

Whenever a new file or directory is created in future it will inherit the default ACLs that have been defined using the first command which means backupuser will get the permissions it needs. Multiple paths to apply the ACLs to can be specified but only one user specification can be put in at a time.

ACLs override the default permissions system when they come into effect and so you need to have good knowledge of how Linux permissions work. In particular you need to ensure your user has x (execute) as well as r (read) permissions specified in ACLs for directories in order to be able to traverse directories, otherwise you will keep getting permissions issues. It took me a bit of work to get the ACLs set up but once they are done properly, the advantage is that inheritable permissions are possible, so for my backups, the backup user will have automatic rights to new files and folders that are created in future. In fact for any computer the way to make it happen is to set a default ACL on /home that gives the backup user rx permissions on everything below in future.

With the ACLs properly set the test backup was able to access all the files it needed to and complete the backup. Since I knew there were roughly 114,000 items waiting for backup, it was interesting to watch rsync at work discovering new files (a big increase from the roughly 7000 it had access to the first time). 

The means of doing the incrementals is still being worked out as it is not as straightforward as I had hoped. The log file is not consistent in its format (at least not so far) that would make it easy to determine which files successfully transferred. The option I am tending towards would probably consist of getting a list of files that have changed since the last backup, then getting rsync to copy one at a time, looking at the result code that it returns, and if there is no error then writing an extended attribute of the source file to indicate a successful backup result. The extended attributes will probably be backup.full = <date> and backup.incr = <date> and these two extended attributes will be written by the appropriate backup script. A full backup simply updates the attribute at backup completion without checking it. Whereas for an incremental, we compare the last modified date in the file with the date stored (backup.incr if set, otherwise backup.full) and do the backup if the file has been modified since the last backup date. So I expect to start more testing reasonably soon with developing scripts to perform these tasks.

But so far as the full backups go, it's doing pretty good. I have just set up another full backup and it's working very well. The second time setting it all up was so much smoother. It also looks like ZFS disk compression works very well and has achieved some useful saving but I will check out exactly what sort of improvement I am getting on these disks.

OpenID sidelined for FB/Google identity lockin

OpenID is a great concept: to help you create a single identity that works across a range of Internet sites. However, it has been falling out of favour in the past few years because both Facebook and Google have provided their own replacements for it.  The reasons for these are supposedly for user convenience. However, the fact is that this convenience comes at a cost. It enables Facebook or Google to collect more information about you for their commercial purposes. It also has the downside that it gives information about you to the third party website, and in some cases a rogue site can use it to post to your social media account without your permission.

Facebook's site originally supported OpenID, but some time ago they replaced it with Facebook Connect, the API that allows you to sign in with Facebook credentials on third party sites. This is good for Facebook that they can drive people to get a Facebook account that they can also use to log into sites. However people have found they are giving too much information and in some cases security privileges to the sites that receive the oAuth token from Facebook.

I wrote this post when I learned that Blogger had dropped support for OpenID. I have never used OpenID for anything at all, but now there won't be much point in using it if all these sites are going to drop it.

The primary concern I have with using Facebook or Google credentials to log into a site is that it represents the same concerns about using a single username and password to log into a lot of sites. Most of the time this will not be an issue, but if there is a problem with your Facebook or Google login, you may find that your access to third party sites is restricted or blocked. 

My own experience is of inappropriate misuse of information released from a social media profile. I remember signing up to the Stuff website with my Facebook credentials. Nek minnit the Stuff website was using my Facebook profile photo and some other details that I didn't want appearing on comments. At that point I deleted the Stuff profile and created another one using a local login.

About the only good thing about using FB or Google credentials to log in is their security is very good and there is less likelihood of your username or password being stolen.

DON'T USE POLi or Account2Account Payment Services they are bad news

These services are for people who do not use a debit or credit card to make a payment. Instead they are transferring funds directly from a bank account to a merchant. The idea of these services is they can make that type of payment as "easy" as a credit or debit card. However they are risky to use, the banks regard them as insecure and would prefer customers do not use them.

These services work by inserting a browser within a browser so that you do a logon into your internet banking in a virtual browser window inside the payment provider's website. Since this requires a secure (HTTPS) connection between you and the bank, the payment provider website must intercept this connection and decrypt the traffic occurring in your supposedly secure and private internet banking session. This is called a "man in the middle" interception and is a system that is used by hackers to steal information from HTTPS logons.

Man in the middle interception of HTTPS traffic is becoming increasingly common in a variety of contexts - not all of them good. The important point is that your supposedly secure and safe internet connection is intercepted somewhere along the way so that it is no longer secure. At the point where it is being transacted between your computer and the payment provider's website, or within the payment provider's website, there is a risk because it is no longer a secure transaction. The payment provider could be storing logon names and passwords, which if obtained by unauthorised parties, could then be used to access your internet banking and steal your money.

The answer is, if you are paying for goods online, don't use an internet banking transfer when a site like this asks you to log into Internet banking in a virtual browser window (where the logon looks like your internet banking logon but is actually within the payment provider's website). Don't provide internet banking credentials anywhere except when logging into the bank's own website. 

Use a debit card or credit card to make all online purchases. Debit cards simply access funds from a nominated account, so they are effectively the same as transferring funds from the account. If your payment website offers to save debit/credit card details against future payments, don't enable the option. You should not have saved any credentials (including debit/credit card numbers) on a third party website which can be insecure.

Although there is also a risk from debit card use, you can limit the amount of funds in the nominated account. This is safer than giving out internet banking credentials, which can be used to gain access to all of your funds,

• http://www.nzherald.co.nz/technology/news/article.cfm?c_id=5&objectid=11596037