Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

In the end, I started to develop my own LSM (Linux Security Module). Currently, it is in the initial stage of development, but already allows to achieve (almost) what I wanted. Here are the basic principles:

  1. User can define up to 64 permissions. Permissions are identified by number, but also may have human-readable aliases. Examples:
  2. 1="Permission to read private photos"
  3. 2="Permission to read and write browser cookies"
  4. 3="Permission to read and write private notes"

  5. Using simple utility, user can mark any file to set:
    a) permissions required to read this file;
    b) permissions required to modify this file;
    c) permissions this file may have if executed.
    Examples:

  6. We make permission #1 (read priv photos) required to read some particular photo file.
  7. We set that program "/bin/firefox" cannot have any permissions if executed (meaningless because this is default).
  8. We set that program "/bin/cat" can have any permissions if executed.
  9. We set that program "/bin/imageview" can have permission #1 but not any other.

  10. IMPORTANT Programs (processes) can't have permissions that their parent doesn't have. Examples:

  11. "/bin/firefox" can't use "/bin/cat" to read private photo. "cat" will lose all permissions if launched by "firefox".

  12. PID 1 (parent of all userspace processes) starts with full permissions. After that, permissions of every program are determined by removing permissions this program doesn't have from it's parent's permissions.

  13. By default, programs have no permissions. And files need no permissions to read/modify them. So enabling my LSM can't break anything.

  14. There are also plans to implement system permissions like "use internet" or "use microphone".

Something like this... Please tell me if you see critical breaches in such logic.

On my PC, I was forced to give full permissions to following programs: systemd, agetty, login, bash, xinit, sh, startkde, start_kdeinit_wrapper, start_kdeinit, kdeinit5, konsole

Now programs I launch from KDE menu or from konsole may have any permissions. But most of them doesn't have any of course.

P.S. Currently I use single uint64_t to store sets of permissions. This allows very fast permission transition and access checks (simple bitwise operations).

In the end, I started to develop my own LSM (Linux Security Module). Currently, it is in the initial stage of development, but already allows to achieve (almost) what I wanted. Here are the basic principles:

  1. User can define up to 64 permissions. Permissions are identified by number, but also may have human-readable aliases. Examples:
  2. 1="Permission to read private photos"
  3. 2="Permission to read and write browser cookies"
  4. 3="Permission to read and write private notes"

  5. Using simple utility, user can mark any file to set:
    a) permissions required to read this file;
    b) permissions required to modify this file;
    c) permissions this file may have if executed.
    Examples:

  6. We make permission #1 (read priv photos) required to read some particular photo file.
  7. We set that program "/bin/firefox" cannot have any permissions if executed (meaningless because this is default).
  8. We set that program "/bin/cat" can have any permissions if executed.
  9. We set that program "/bin/imageview" can have permission #1 but not any other.

  10. IMPORTANT Programs (processes) can't have permissions that their parent doesn't have. Examples:

  11. "/bin/firefox" can't use "/bin/cat" to read private photo. "cat" will lose all permissions if launched by "firefox".

  12. PID 1 (parent of all userspace processes) starts with full permissions. After that, permissions of every program are determined by removing permissions this program doesn't have from it's parent's permissions.

  13. By default, programs have no permissions. And files need no permissions to read/modify them. So enabling my LSM can't break anything.

  14. There are also plans to implement system permissions like "use internet" or "use microphone".

Something like this... Please tell me if you see critical breaches in such logic.

On my PC, I was forced to give full permissions to following programs: systemd, agetty, login, bash, xinit, sh, startkde, start_kdeinit_wrapper, start_kdeinit, kdeinit5, konsole

Now programs I launch from KDE menu or from konsole may have any permissions. But most of them doesn't have any of course.

P.S. Currently I use single uint64_t to store sets of permissions. This allows very fast permission transition and access checks (simple bitwise operations).

In the end, I started to develop my own LSM (Linux Security Module). Currently, it is in the initial stage of development, but already allows to achieve (almost) what I wanted. wanted. Here are the basic principles:

  1. User can define up to 64 permissions. Permissions are identified by number, but also may have human-readable aliases. Examples:


  2. 1="Permission to read private photos"

  3. 2="Permission to read and write browser cookies"

  4. 3="Permission to read and write private notes"

  5. Using simple utility, user can mark any file to set:
    a) permissions required to read this file;
    b) permissions required to modify this file;
    c) permissions this file may have if executed.
    Examples:


  6. We make permission #1 (read priv photos) required to read some particular photo file.

  7. We set that program "/bin/firefox" cannot have any permissions if executed (meaningless because this is default).

  8. We set that program "/bin/cat" can have any permissions if executed.

  9. We set that program "/bin/imageview" can have permission #1 but not any other.

  10. IMPORTANT Programs (processes) can't have permissions that their parent doesn't have. Examples:


  11. "/bin/firefox" can't use "/bin/cat" to read private photo. "cat" will lose all permissions if launched by "firefox".

  12. PID 1 (parent of all userspace processes) starts with full permissions. After that, permissions of every program are determined by removing permissions this program doesn't have from it's parent's permissions.

  13. By default, programs have no permissions. And files need no permissions to read/modify them. So enabling my LSM can't break anything.

  14. There are also plans to implement system permissions like "use internet" or "use microphone".

Something like this... Please tell me if you see critical breaches in such logic.

On my PC, I was forced to give full permissions to following programs: systemd, agetty, login, bash, xinit, sh, startkde, start_kdeinit_wrapper, start_kdeinit, kdeinit5, konsole

Now programs I launch from KDE menu or from konsole may have any permissions. But most of them doesn't have any of course.

P.S. Currently I use single uint64_t to store sets of permissions. This allows very fast permission transition and access checks (simple bitwise operations).

In the end, I started to develop my own LSM (Linux Security Module). Currently, it is in the initial stage of development, but already allows to achieve (almost) what I wanted. Here are the basic principles:

  1. User can define up to 64 permissions. Permissions are identified by number, but also may have human-readable aliases. Examples:
    a) 1="Permission to read private photos"
    b) 2="Permission to read and write browser cookies"
    c) 3="Permission to read and write private notes"

  2. Using simple utility, user can mark any file to set:
    a) permissions required to read this file;
    b) permissions required to modify this file;
    c) permissions this file may have if executed.
    Examples:
    a) We make permission #1 (read priv photos) required to read some particular photo file.
    b) We set that program "/bin/firefox" cannot have any permissions if executed (meaningless because c) this is default).
    d) We set that program "/bin/cat" can have any permissions if executed.
    e) We set that program "/bin/imageview" can have permission #1 but not any other.

  3. IMPORTANT Programs (processes) can't have permissions that their parent doesn't have. Examples:
    a) "/bin/firefox" can't use "/bin/cat" to read private photo. "cat" will lose all permissions if launched by "firefox".

  4. PID 1 (parent of all userspace processes) starts with full permissions. After that, permissions of every program are determined by removing permissions this program doesn't have from it's parent's permissions.

  5. By default, programs have no permissions. And files need no permissions to read/modify them. So enabling my LSM can't break anything.

  6. There are also plans to implement system permissions like "use internet" or "use microphone".

Something like this... Please tell me if you see critical breaches in such logic.

On my PC, I was forced to give full permissions to following programs: systemd, agetty, login, bash, xinit, sh, startkde, start_kdeinit_wrapper, start_kdeinit, kdeinit5, konsolekonsole.

Now programs I launch from KDE menu or from konsole may have any permissions. But most of them doesn't have any of course.

P.S. Currently I use single uint64_t to store sets of permissions. This allows very fast permission transition and access checks (simple bitwise operations).

In the end, I started to develop my own LSM (Linux Security Module). Currently, it is in the initial stage of development, but already allows to achieve (almost) what I wanted. Here are the basic principles:

  1. User can define up to 64 permissions. Permissions are identified by number, but also may have human-readable aliases. Examples:
    a) 1="Permission to read private photos"
    b) 2="Permission to read and write browser cookies"
    c) 3="Permission to read and write private notes"

  2. Using simple utility, user can mark any file to set:
    a) permissions required to read this file;
    b) permissions required to modify this file;
    c) permissions this file may have if executed.
    Examples:
    a) We make permission #1 (read priv photos) required to read some particular photo file.
    b) We set that program "/bin/firefox" cannot have any permissions if executed (meaningless because c) this is default).
    d) c) We set that program "/bin/cat" can have any permissions if executed.
    e) d) We set that program "/bin/imageview" can have permission #1 but not any other.

  3. IMPORTANT Programs (processes) can't have permissions that their parent doesn't have. Examples:
    a) "/bin/firefox" can't use "/bin/cat" to read private photo. "cat" will lose all permissions if launched by "firefox".

  4. PID 1 (parent of all userspace processes) starts with full permissions. After that, permissions of every program are determined by removing permissions this program doesn't have from it's parent's permissions.

  5. By default, programs have no permissions. And files need no permissions to read/modify them. So enabling my LSM can't break anything.

  6. There are also plans to implement system permissions like "use internet" or "use microphone".

Something like this... Please tell me if you see critical breaches in such logic.

On my PC, I was forced to give full permissions to following programs: systemd, agetty, login, bash, xinit, sh, startkde, kdeinit5, konsole.

Now programs I launch from KDE menu or from konsole may have any permissions. But most of them doesn't have any of course.

P.S. Currently I use single uint64_t to store sets of permissions. This allows very fast permission transition and access checks (simple bitwise operations).