[SECURITY] CoreFreq access limitation

[cyring]

Limitation is based on the Linux security.

The Daemon can be launched with a User and/or Group passed as options.

1. For example, presuming 65432 is the uid of nobody and 987 is the gid of users, run as root the Daemon like bellow:

corefreqd -d -U 65432 -G 987

• Check the shared memories:

ls -l /dev/shm/

-rw-r----- 1 nobody users 244K Jan  4 17:39 corefreq-ro-shm
-rw-rw---- 1 nobody users 4.0K Jan  4 17:38 corefreq-rw-shm

2. You can now start the Client from any account which belongs to the group users

• In the contrary case, corefreq-cli will output the following error:

Daemon connection error code 13
corefreq-ro-shm: 'Permission denied' @ line 18604

The default case

This is the major change in CoreFreq.
If you don't supply any options, the Daemon will set both uid and gid to root; thus only root will be able to run corefreq-cli

-rw-r----- 1 root root 244K Jan  4 18:10 corefreq-ro-shm
-rw-rw---- 1 root root 4.0K Jan  4 18:10 corefreq-rw-shm

Testings

This change is so far available in the develop branch.

It has been especially made for Datacenters, Production, and other online systems.

I will appreciate any returns, criticisms, any attempt to break this security ...

[cyring]

Commit fd22d04 is enhancing the -M option of corefreqd to pass in octal the permission bits of the two shared memories; in order, corefreq-ro-shm, corefreq-rw-shm

The default mode (no option supplied) is a permissive mode for all users:

-r--r--r-- 1 root root 249856 Jan  6 07:08 corefreq-ro-shm
-rw-rw-rw- 1 root root   4096 Jan  6 07:08 corefreq-rw-shm

If your Organization requires a more secured mode, you can combine the 3 options -M, -U, and -G.

For example, restricting the CoreFreq access to a unique account:

corefreqd -M 0400,0600 -U $(id -u cyril) -G $(id -g nobody)

-r-------- 1 cyril nobody 249856 Jan  6 07:19 corefreq-ro-shm
-rw------- 1 cyril nobody   4096 Jan  6 07:19 corefreq-rw-shm