Acl

Общее

ACL — это набор текстовых выражений, которые что-то разрешают, либо что-то запрещают. Обычно ACL разрешает или запрещает IP-пакеты, но помимо всего прочего он может заглядывать внутрь IP-пакета, просматривать тип пакета, TCP и UDP порты. Также ACL существует для различных сетевых протоколов (IP, IPX, AppleTalk и так далее). В основном применение списков доступа рассматривают с точки зрения пакетной фильтрации, то есть пакетная фильтрация необходима в тех ситуациях, когда у вас стоит оборудование на границе Интернет и вашей частной сети и нужно отфильтровать ненужный трафик.
Вы размещаете ACL на входящем направлении и блокируете избыточные виды трафика.

Устоявшиеся истины:

• Каждый пользователь входит в минимум одну группу. Группа, присваиваемая пользователю при его создании, называется основной. Все остальные группы в которые будет включен пользователь, будут являться дополнительными.1)
• Группа пользователей может содержать некоторое количество пользователей, но не может содержать или включаться в другие группы.
• Группа может быть пустой, т.е. не содержать в себе ни одного пользователя.

What Are The Types of ACLs?

There are four types of ACLs that you can use for different purposes, these are standard, extended, dynamic, reflexive, and time-based ACLs.

1. Standard ACL

The standard ACL aims to protect a network using only the source address.

It is the most basic type and can be used for simple deployments, but unfortunately, it does not provide strong security. The configuration for a is as follows:

2. Extended ACL

With the extended ACL, you can also block source and destination for single hosts or entire networks.

You can also use an extended ACL to filter traffic based on protocol information (IP, ICMP, TCP, UDP).

The configuration of an for TCP is as follows:

3. Dynamic ACL

Dynamic ACLs, rely upon extended ACLs, Telnet, and authentication. This type of ACLs are often referred to as “Lock and Key” and can be used for specific timeframes.

These lists permit access to a user to a source or destination only if the user authenticates to the device via Telnet.

The following is the configuration of a .

4. Reflexive ACL

Reflexive ACLs are also referred to as IP session ACLs. These type of ACLs, filter traffic based on upper layer session information.

They react to sessions originated inside the router to whether permit outbound traffic or restrict incoming traffic. The router recognizes the outbound ACL traffic and creates a new ACL entry for the inbound.

When the session finishes, the entry is removed.

The configuration of a is as follows:

Comparing with RBAC

The main alternative to the ACL model is the role-based access-control (RBAC) model. A «minimal RBAC model», RBACm, can be compared with an ACL mechanism, ACLg, where only groups are permitted as entries in the ACL. Barkley (1997) showed that RBACm and ACLg are equivalent.

In modern SQL implementations, ACLs also manage groups and inheritance in a hierarchy of groups. So «modern ACLs» can express all that RBAC express, and are notably powerful (compared to «old ACLs») in their ability to express access-control policy in terms of the way in which administrators view organizations.

For data interchange, and for «high level comparisons», ACL data can be translated to XACML.

Интерфейс программы

Рис.1 Главное окно

На рисунке 1 представлено главное окно программы со следующими элементами:

1 — поле ввода access-листа
2 — поле ввода object-групп
3 — запуск распознавания access-листа
4 — поле вывода распознанного access-листа
5 — однострочное поле ввода условия
6 — многострочный список ввода условий
7 — прямая проверка условия
8 — обратная проверка условия
9 — поле результата проверки
10 — шкала позиционирования сработавших строк ACL
11 — поле просмотра деталей сработавших строк ACL
12 — анализ ACL на конфликты и избыточность
13 — упорядочивание строк ACL по различным критериям
14 — указатель текущего активного условия в многострочном списке (6)
15 — поле краткого обозначения результатов проверки списка условий (6)
16 — переключатель типа маски
17 — переключатель алгоритма проверки адресов источника и назначения
18 — игнорирование строк ACL с ICMP в режиме частичного совпадения адресов
19 — выбор вариантов использования имени ACL в командах CLI
20 — вывод object-групп, используемых в распознанном ACL
21 — вывод поддерживаемых протоколов, а также типов и кодов ICMP
22 — поле вывода ошибок распознавания ACL

Управление доступом к файлам

chmod

— изменение битов режима доступа к файлу.

chmod 

chmod -R 711 /usr/local/scripts
— право выполнения на все файлы в каталоге, для группы и всех остальных.

chmod g-w passwords.txt
— отнять у группы право записи.

chmod og+r menu.txt guests.txt
— добавить группе и всем остальным пользователям право чтения.

сhmod g-x, o= script.sh
— отнять право выполнения у группы, всем остальным запретить доступ к файлу.

сhmod g=u userlist.txt
— группе выдаются такие же права, что и у владельца файла.

chmod —reference=file1 file2
— скопировать права file1 для file2

chown

— изменение владельца файлов и каталогов.

chown  

chown jane report.doc stats.txt
— пользователь jane становится владельцем файлов report.doc и stats.txt.

chown jane: report.doc
— пользователь jane становится владельцем файла report.doc. Также группа владельцев меняется на jane.

chown :accounters report.doc
— смена группы владельцев файла report.doc.

chown john:accounters report.doc
— пользователь john становится владельцем файла report.doc. У файла также меняется группа владельцев, к которой он принадлежит на accounters.

chown -R jane:testers /var/www/example.ru/fortest
— рекурсивная смена пользователя и группы для всех файлов в каталоге.

chown 1003:1004 /var/www/example.ru
— установка владельца c UID(UserID)=1003 и группы c GID(GroupID)=1004.

chown -Rc —reference ~/music ~/pictures
— рекурсивное копирование владельца и группы у ~/music для всех файлов в каталоге ~/pictures

chgrp

— смена группы пользователей для файла.

chgrp 

chgrp designers logo.png
— установка группы пользователей designers для файла logo.png.

chgrp -R accounters ~/reports
— установка группы пользователей accounters для всех файлов в каталоге ~/reports.

getfacl

— вывод списка контроля доступа (ACL) для файла.

getfacl 

getfacl file.txt

getfacl -t file.txt
— вывод параметров доступа в табличном виде.

getfack -Rt ~/reports
— вывод параметров доступа для всех файлов в каталоге.

sudo

— запуск команды от имени другого пользователя (root по умолчанию)

sudo 

sudo -u janedoe mkdir ~janedoe/reports
— выполнить команду от имени пользователя janedoe.

sudo mkdir /var/www
— выполнить команду от имени пользователя root.

umask

— изменение маски прав доступа по умолчанию при создании нового файла.

umask 

umask
— показать текущую маску по умолчанию.

umask u+w,g-w,o=
— добавить право записи для владельца — , отнять право записи для группы — , для остальных пользователей запретить доступ к файлу .

umask a=rw
— установить право записи и чтения для всех пользователей.

umask 0000
— полный доступ для всех пользователей. (так не надо делать :-))

Implementations

Many kinds of operating systems implement ACLs, or have a historical implementation. The first time in the filesystem of Multics in 1965.

Filesystem ACLs

A filesystem ACL is a data structure (usually a table) containing entries that specify individual user or group rights to specific system objects such as programs, processes, or files. These entries are known as access-control entries (ACEs) in the Microsoft Windows NT,OpenVMS, Unix-like, and macOS operating systems. Each accessible object contains an identifier to its ACL. The privileges or permissions determine specific access rights, such as whether a user can read from, write to, or execute an object. In some implementations, an ACE can control whether or not a user, or group of users, may alter the ACL on an object.

PRIMOS featured ACLs at least as early as 1984.

In the 1990s the ACL and RBAC models were extensively tested[] and used to administer file permissions.

POSIX ACL

POSIX 1003.1e/1003.2c working group made an effort to standardize ACLs, resulting in what is now known as «POSIX.1e ACL» or simply «POSIX ACL». The POSIX.1e/POSIX.2c drafts were withdrawn in 1997 due to participants losing interest for funding the project and turning to more powerful alternatives such as NFSv4 ACL. As of December 2019, no live sources of the draft could be found on the Internet, but it can still be found in the Internet Archive.

Most of the Unix and Unix-like operating systems (e.g. Linux since 2.5.46 or November 2002,BSD, or Solaris) support POSIX.1e ACLs (not necessarily draft 17). ACLs are usually stored in the extended attributes of a file on these systems.

NFSv4 ACL

The NFSv4 ACL is much more powerful than POSIX draft ACL. Unlike the draft POSIX ACL, as part of the Network File System, NFSv4 ACL is defined by an actually published standard.

NFSv4 ACLs are supported by many Unix and Unix-like operating systems. Examples include AIX, FreeBSD,Mac OS X beginning with version 10.4 («Tiger»), or Solaris with ZFS filesystem, support NFSv4 ACLs, which are part of the NFSv4 standard. There are two experimental implementations of NFSv4 ACLs for Linux: NFSv4 ACLs support for Ext3 filesystem and the more recent Richacls which brings NFSv4 ACLs support for Ext4 filesystem. As with POSIX ACL, NFSv4 ACL is usually stored as extended attributes on Unix-like systems.

The NFSv4 ACL is organized near-identically to the Windows NT ACLs used in NTFS. NFSv4.1 ACL is a superset of both NT ACL and POSIX draft ACL. Samba supports saving the NT ACL of SMB-shared files in many ways, one of which is as NFSv4-encoded ACLs.

Active Directory ACLs

Microsoft’s Active Directory Directory Service implements an LDAP server that store and disseminate configuration information about users and computers in a domain. Active Directory extends the LDAP specification by adding the same type of access-control list mechanism as Windows NT uses for the NTFS filesystem. Windows 2000 then extended the syntax for access control entries such that they could not only grant or deny access to entire LDAP objects, but also to individual attributes within these objects.

Networking ACLs

On some types of proprietary computer-hardware (in particular routers and switches), an access-control list provides rules that are applied to port numbers or IP addresses that are available on a host or other layer 3, each with a list of hosts and/or networks permitted to use the service. Although it is additionally possible to configure access-control lists based on network domain names, this is a questionable idea because individual TCP, UDP, and ICMP headers do not contain domain names. Consequently, the device enforcing the access-control list must separately resolve names to numeric addresses. This presents an additional attack surface for an attacker who is seeking to compromise security of the system which the access-control list is protecting. Both individual servers as well as routers can have network ACLs. Access-control lists can generally be configured to control both inbound and outbound traffic, and in this context they are similar to firewalls. Like firewalls, ACLs could be subject to security regulations and standards such as PCI DSS.

ACL algorithms have been ported to SQL and to relational database systems. Many «modern» (2000s and 2010s) SQL-based systems, like enterprise resource planning and content management systems, have used ACL models in their administration modules.

»Configuring ACLs

ACLs are configured using several different configuration options. These are marked
as to whether they are set on servers, clients, or both.

Configuration Option	Servers	Clients	Purpose
			Controls whether ACLs are enabled
			Determines allowlist or denylist mode
			Determines what to do when the remote token or policy resolution fails
			Determines time-to-live for cached ACL Roles
			Determines time-to-live for cached ACL Policies
			Determines time-to-live for cached ACL Tokens

A number of special tokens can also be configured which allow for bootstrapping the ACL
system, or accessing Consul in special situations:

Special Token	Servers	Clients	Purpose
			Special token that can be used to access Agent API when remote bearer token resolution fails; used for setting up the cluster such as doing initial join operations, see the section for more details
			Special token that is used for an agent’s internal operations, see the section for more details
			Special token used to bootstrap the ACL system, see the Bootstrapping ACLs guide for more details
			Default token to use for client requests where no token is supplied; this is often configured with read-only access to services to enable DNS service discovery on agents

All of these tokens except the token can all be introduced or updated via the .

ACL Agent Master Token

Since the is designed to be used when the Consul servers are not available, its policy is managed locally on the agent and does not need to have a token defined on the Consul servers via the ACL API. Once set, it implicitly has the following policy associated with it

ACL Agent Token

The is a special token that is used for an agent’s internal operations. It isn’t used directly for any user-initiated operations like the , though if the isn’t configured the will be used. The ACL agent token is used for the following operations by the agent:

1. Updating the agent’s node entry using the Catalog API, including updating its node metadata, tagged addresses, and network coordinates
2. Performing anti-entropy syncing, in particular reading the node metadata and services registered with the catalog
3. Reading and writing the special section of the KV store when executing commands

Here’s an example policy sufficient to accomplish the above for a node called :

The policy needs read access for any services that can be registered on the agent. If , the default, then the policy can be omitted.

Анализ на конфликты и избыточность (кнопка 12)

Кнопка “Анализ” (12) становится активной после распознания access-листа. Её нажатие запускает процесс анализа строк access-листа на конфликты и избыточность. Конфликтующей является строка access-листа, которая никогда не сработает из-за вышестоящего правила противоположного значения (“deny” после “permit” или наоборот).

К примеру, загрузим следующий ACL:

Распознаем его (кнопка 3) и нажмём кнопку “Анализ” (12). Программа предупредит нас о имеющихся конфликтах (рис. 8):

Рис.8 Сообщение о наличии конфликтов

Кнопка “Да” откроет окно с результатами анализа, включающими только конфликты (рис. 9):

Рис.9 Окно результатов анализа конфликтов

Если нажать кнопку ‘Нет’ (рис.8), то откроется окно, включающее как конфликтующие, так и избыточные правила.

Рассмотрим следующий access-list:

Анализ такого ACL отобразит следующие результаты:

Рис.10 Окно результатов анализа

Жирным шрифтом выделены строки, описывающие более общие правила для других более детальных правил, имеющихся в ACL. Далее такие избыточные более детальные правила будем называть производными. Остальные строки (обычный шрифт) являются производными правилами.

Установив курсор на определённой строке с нажатой клавишей “Ctrl”, получим детальную информацию в нижней части окна (рис.11):

Рис.11 Детализация анализа строки

1 — поле результатов
2 — поле детализации выбранного правила
3 — иерархический вид детализации

В данном случае правило 2 является производным от правила 3. В свою очередь, правило 3 входит в правило 4. Визуально уровень такой вложенности можно определить по отступам строки вправо или выбрать иерархический вид (3). При иерархическом виде производные правила будут выведены ниже строк, в которые они входят. В поле 1 можно выделить диапазон интересуемых строк и вызвать контекстное меню (правой кнопкой мыши) со следующими вариантами действий над результатами анализа:

• “Cкопировать всё”. Данный выбор копирует все правила поля 1 с исходными номерами строк вне зависимости от выделенного диапазона;
• “Скопировать с префиксом ‘no’”. Данный пункт скопирует правила выделенного диапазона с префиксом ‘no’ вначале каждой строки. Номера строк не копируются. Используется для безусловного удаления строк из ACL;
• “Скопировать с префиксом ‘no’ избыточные правила”. Данный пункт скопирует избыточные правила выделенного диапазона с префиксом ‘no’ вначале каждой строки. Номера строк не копируются;
• “Скопировать с префиксом ‘no’ избыточные правила, не имеющие производных”. Данный пункт работает как и предыдущий, но для правил, которые сами по себе не имеют производных от них избыточных правил. Рекомендован для поэтапного удаления избыточных правил от более детальных к более общим. После каждого прохода необходимо загружать обновлённый ACL и анализировать его заново. Такой способ позволяет принять решение по оптимизации правил на определённом уровне детализации;
• “Скрыть производные этого вхождения”. Пункт исключает из результатов текущее указанное правило и производные от него.

Загрузим и проанализируем следующий access-лист:

В окне анализа (рис.12) подробности по сроке 2 можно получить двумя способами:

• установить на неё курсор с нажатой клавишей “Ctrl”;
• установить на неё курсор, а затем нажать “Enter”.

Рис.12 Множественная избыточность.

По цветовому выделению можно определить для каких более общих правил эта строка является производной (избыточной).

Следует учитывать, что избыточные строки access-листа, полученные из object-групп, нельзя удалить, т.к. в исходном ACL они не присутствуют отдельными правилами. По этой причине при попадании таких строк в диапазон к удалению они не будут скопированы, а на экране появится предупреждение (рис.13):

Рис.13 Предупреждение об исключении групповых правил.

В некоторых случаях операторы “permit” и “deny” намеренно присутствуют в определённых местах одного ACL для его упрощения. Следует учитывать этот факт и анализировать такие ACL частями. Например, до и после операторов “deny”

Либо анализировать полностью, но дополнительно обращать внимание на порядок следования конфликтующих строк в ACL и не удалять такие производные строки из исходного ACL

Порядок просмотра ACL

ACL — это набор правил. Каждое правило состоит из действия (permit, deny) и критерия (для стандартных ACL — ip адрес отправителя, для расширенных — множество критериев). Рассмотрим такой пример стандартного нумерованного ACL:

access-list 1 permit host 192.168.1.1
access-list 1 deny 192.168.1.0
access-list 1 permit any

Этот ACL запрещает доступ для всей сети 192.168.1.0/24 кроме хоста 192.168.1.1 и разрешает доступ для всех остальных сетей. Как проверяется трафик на соответствие ACL? Построчно

То есть, приходит, например, пакет с адреса 192.168.2.2 на роутер, а на том интерфейсе через который он пришел стоит на вход указанный выше ACL, вот построчно Ip адрес отправителя сверяется с данным ACL, что важно — до первого совпадения. Как только пакет совпадёт с какой-то из строк, сработает действие (permit — пропустить пакет либо deny — уничтожить пакет) и дальше никаких проверок по оставшимся строчкам проводиться не будет

Если все строчки пройдены, а пакет так и не попал ни под одно из правил, то он по умолчанию уничтожается. В нашем случае, в примере выше любой пакет подходит под третью строчку, так как там вместо адреса стоит слово «any», означающее, что любой адрес подойдёт. Таким образом, приведённый ACL можно читать так:

• Если пакет пришёл с адреса 192.168.1.1, то его надо сразу же пропустить и не делать больше никаких проверок в этом ACL;
• В противном случае, если пакет пришел из сети 192.168.1.0 (кроме адреса 192.168.1.1, с которым мы уже разобрались строчкой выше), то пакет надо уничтожить и опять же, на этом закончить просмотр ACL, не переходить к следующему шагу;
• Если пакет не попал под первые два правила. То есть он не с адреса 192.168.1.1, да и вообще, не из сети 192.168.1.0, то он всегда попадает под правило permit any, то есть, пакет надо пропустить дальше — пусть идёт.

Очень важно понимать приведённый выше порядок просмотра строк в ACL, он един для всех типов ACL (не только для стандартного). Кроме того, из этого порядка следует очевидное правило: «В ACL-е должны идти наиболее специфичные, узкие, точные строчки вначале и наиболее абстрактные, общие — в конце».

Who Is a Grantee?

When you grant access rights, you specify each grantee as a type=value
pair, where the type is one of the following:

• – if the value specified is the canonical user ID of an AWS account

• – if you are granting permissions to a predefined group

Important

• US East (N. Virginia)

• US West (N. California)

• US West (Oregon)

• Asia Pacific (Singapore)

• Asia Pacific (Sydney)

• Asia Pacific (Tokyo)

• Europe (Ireland)

• South America (São Paulo)

For a list of all the Amazon S3 supported regions and endpoints,
see in the
AWS General Reference.

Warning

When you grant other AWS accounts access to your resources, be aware that the AWS
accounts can delegate their permissions to users under their
accounts. This is known as cross-account
access. For information about using cross-account access,
see
Creating a Role to Delegate Permissions to an IAM User
in the IAM User Guide.

Finding an AWS Account Canonical User
ID

The canonical user ID is associated with your AWS account. It is a long string, such
as
.
For information about how to find the canonical user ID for your account, see
.

You can also look up the canonical user ID of an AWS account by reading the
ACL of a bucket or an object to which the AWS account has access permissions.
When an individual AWS account is granted permissions by a grant request, a
grant entry is added to the ACL with the AWS account’s canonical user ID.

Note

If you make your bucket public (not recommended) any unauthenticated user can upload
objects to the bucket. These anonymous users don’t have an AWS account. When
an
anonymous user uploads an object to your bucket Amazon S3 adds a special
canonical user ID () as the
object owner in the ACL. For more information, see .

Amazon S3 Predefined Groups

Amazon S3 has a set of predefined groups. When granting account access to a group,
you specify one of our URIs instead of a canonical user ID. We provide the
following predefined groups:

• Authenticated Users
  group – Represented by
  .

  This group represents all AWS accounts. Access permission to this
  group allows any AWS account to access the resource. However, all
  requests must be signed (authenticated).

  Warning

  When you grant access to the Authenticated Users group
  any AWS authenticated user in the world can access your
  resource.

• All Users group –
  Represented by
  .

  Access permission to this group allows anyone in the world access
  to the resource. The requests can be signed
  (authenticated) or unsigned (anonymous). Unsigned requests omit the
  Authentication header in the request.

  Warning

  We highly recommend that you never grant the All Users
  group
  , , or
  permissions. For example,
  permissions allow anyone to store objects in
  your bucket, for which you are billed. It also allows others to
  delete objects that you might want to keep. For more details about
  these permissions, see the following section .

• Log Delivery group
  – Represented by
  .

  WRITE permission on a bucket enables this group to write server
  access logs (see Amazon S3 server access logging) to the bucket.

Note

When using ACLs, a grantee can be an AWS account or one of the predefined Amazon S3
groups.
However, the grantee cannot be an IAM user. For more information about AWS
users and permissions within IAM, go to Using
AWS Identity and Access Management.

What Is an Access Control List

An access control list (ACL) contains rules that grant or deny access to certain digital environments. There are two types of ACLs:

• Filesystem ACLs━filter access to files and/or directories. Filesystem ACLs tell operating systems which users can access the system, and what privileges the users are allowed.
• Networking ACLs━filter access to the network. Networking ACLs tell routers and switches which type of traffic can access the network, and which activity is allowed.

Originally, ACLs were the only way to achieve firewall protection. Today, there are many types of firewalls and alternatives to ACLs. However, organizations continue to use ACLs in conjunction with technologies like virtual private networks (VPNs) that specify which traffic should be encrypted and transferred through a VPN tunnel.

Reasons to use an ACL:

• Traffic flow control
• Restricted network traffic for better network performance
• A level of security for network access specifying which areas of the server/network/service can be accessed by a user and which cannot
• Granular monitoring of the traffic exiting and entering the system