What is nss linux

nss(5) — Linux man page

Each call to a function which retrieves data from a system database like the password or group database is handled by the Name Service Switch implementation in the GNU C library. The various services provided are implemented by independent modules, each of which naturally varies widely from the other.

The default implementations coming with the GNU C library are by default conservative and do not use unsafe data. This might be very costly in some situations, especially when the databases are large. Some modules allow the system administrator to request taking shortcuts if these are known to be safe. It is then the system administrator’s responsibility to ensure the assumption is correct.

There are other modules where the implementation changed over time. If an implementation used to sacrifice speed for memory consumption it might create problems if the preference is switched.

The /etc/default/nss file contains a number of variable assignments. Each variable controls the behavior of one or more NSS modules. White spaces are ignored. Lines beginning with ‘#’ are treated as comments.

The variables currently recognized are: NETID_AUTHORITATIVE = TRUE|FALSE If set to TRUE, the NIS backend for the initgroups(3) function will accept the information from the netid.byname NIS map as authoritative. This can speed up the function significantly if the group.byname map is large. The content of the netid.byname map is used as is. The system administrator has to make sure it is correctly generated. SERVICES_AUTHORITATIVE = TRUE|FALSE If set to TRUE, the NIS backend for the getservbyname(3) and getservbyname_r(3) functions will assume that the services.byservicename NIS map exists and is authoritative, particularly that it contains both keys with /proto and without /proto for both primary service names and service aliases. The system administrator has to make sure it is correctly generated. SETENT_BATCH_READ = TRUE|FALSE If set to TRUE, the NIS backend for the setpwent(3) and setgrent(3) functions will read the entire database at once and then hand out the requests one by one from memory with every corresponding getpwent(3) or getgrent(3) call respectively. Otherwise each getpwent(3) or getgrent(3) call might result in a network communication with the server to get the next entry.

Files

Example

The default configuration corresponds to the following configuration file:

NETID_AUTHORITATIVE=FALSE SERVICES_AUTHORITATIVE=FALSE SETENT_BATCH_READ=FALSE

Источник

What is nss linux

Linux – система многопользовательская. По умолчанию, большинство дистрибутивов используют «классический» набор файлов в которых хранится информация о пользователях и группах: /etc/passwd , /etc/group , /etc/shadow , /etc/gshadow . Во многих ситуациях этого вполне достаточно, но иногда возникает необходимость в интеграции Linux в более или менее чужеродное, либо просто распределенное окружение, и именно в этот момент к нам на помощь приходят такая интересная подсистема, как NSS – Name Service Switch. Основная задача NSS – создать модульное окружение для управления пользователями. Реализовано это посредством загружаемых библиотек. Основные вызовы NSS реализованы в библиотеке libc, а libc в свою очередь загружает и вызывает бакэнды NSS:

При инициализации программы, так или иначе связанной с NSS, загружаются основная библиотека libc.so , которая считывает конфигурацию из файла /etc/nsswitch.conf , после чего также загружаются те библиотеки NSS, которые указаны в этом файле.

Впоследствии при работе программы, если программе требуется работать с именованными сущностями, соответствующие вызовы функций glibc будут обращаться к функциям NSS и использовать в те источники данных, которые указаны в nsswitch.conf .

В частности, через NSS можно разрешать (определять) имена и идентификаторы протоколов, номера портов служб (сервисов), имена и идентификаторы пользователей и групп, IP-адреса и имена компьютеров и некоторые другие данные.

Пример файла nsswitch.conf :

$ cat /etc/nsswitch.conf passwd: files ldap shadow: files ldap group: files ldap hosts: files dns bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: nisplus publickey: nisplus automount: files nisplus aliases: files nisplus

В данном примере указано, что для определения имен пользователей и групп используются сначала текстовые файлы и затем LDAP, для определения имен компьютеров и IP-адресов используются сначала текстовые файлы и затем DNS, для определения алиасов и настроек автоматического монтирования каталогов используются сначала текстовые файлы и затем служба NIS+.

Библиотеки бакэндов системы NSS хранятся в файлах libnss_ XXX .so , где XXX – это имя бакэнда. Например libnss_files.so – это бакэнд NSS использующий в качестве источника данных текстовые файлы, libnss_db.so – бакэнд использующий файлы BerkleyDB, libnss_ldap.so – бакэнд позволяющий хранить данные в каталоге LDAP. Как правило, каждый бакэнд имеет свои дополнительные конфигурационные файлы.

Как следствие, если у вас возникла необходимость использовать вашу Linux-систему в сетевом или чужеродном окружении и обеспечить ее интеграцию с ним, вы можете воспользоваться NSS и получить доступ к информации через соответствующий бакэнд – например, для интеграции в среду Solaris, вы можете воспользоваться бакэндом NIS/NIS+, для интеграции в ActiveDirectory – бакэндом LDAP.

При этом модульность NSS позволяет вам объединять различные источники данных – например, использовать текстовые файлы и DNS для определения имен компьютеров, NIS для определения имен протоколов и сервисов, и текстовые файлы и LDAP для определения имен и идентификаторов пользователей и групп.

Подсистема PAM (Pluggable Authentification Modules) идейно очень схожа с NSS, но отличается от нее назначением. Основная задачам PAM – аутентификация пользователей (проверка паролей, прав доступ, ограничений и так далее). Как и NSS, PAM состоит из набора основных библиотек и бакэндов, причем необходимые бакэнды, порядок их вызова и некоторые опциональные параметры определяются в конфигурационных файлах PAM, обычно они расположены в каталоге /etc/pam.d . Главным отличием PAM от NSS (кроме естественно назначения) является то, что PAM является не составной и неотъемлемой частью libc, а отдельным множеством библиотек.

Основная часть стандартных утилит UNIX для управления пользователями и группами и получения информации о них, в большинстве дистрибутивов Linux общего назначения, адаптирована и собрана с поддержкой NSS и PAM. К таким утилитам относятся passwd , chsh , chfn , id , who и другие. NSS также используется даже такими утилитами как ls , find , ps – то есть всеми теми программами, которые отображают имя пользователя. Соответственно, если программа запрашивает у пользователя пароль – скорее всего она использует и NSS, и PAM (например XDM или GDM). Большинство программ в чьи функции входит обработка почты также используют NSS. Соответственно, можно уверенно говорить что подсистемы NSS и PAM и базовые знания об их предназначении на сегодняшний день являются необходимыми для администратора Linux-систем.

Источник

Network Security Services

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications.

Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.

NSS is required by many packages, including, for example, Chromium and Firefox.

Installation

Usage

NSS is implemented in terms of operations on a dynamically configured list of PKCS #11 modules. Each module can execute cryptographic operations and store cryptographic objects. The configured list of modules is usually stored in an arbitrary directory, provided by a user at initialization of NSS, in the file pkcs11.txt . The list always contains a built-in module «NSS Internal PKCS #11 Module» with tokens «NSS Generic Crypto Services» and «NSS Certificate DB». The first token provides cryptographic mechanisms such as RSA, SHA256, TLS etc. The second token stores certificates and private keys in the same user-provided directory in the files cert9.db and key4.db . The files pkcs11.txt , cert9.db and key4.db are also called «NSS databases». Paths to NSS databases for some applications are listed in the table below. You should provide some path for each operation. Examples below will use ~/.pki/nssdb/ .

Application	Path to NSS databases
chromium , evolution	~/.pki/nssdb/
firefox	~/.mozilla/firefox//
thunderbird	~/.thunderbird//
libreoffice-fresh	configurable via Options [1]

For managing PKCS #11 modules NSS provides the modutil(1) utility, for managing certificates and private keys — the certutil(1) utility.

Note: NSS can automatically add /usr/lib/libnssckbi.so to the list of PKCS #11 modules depending on initialization flags.

List certificate DB

To get list of all certificates:

To get details about certificate:

$ certutil -d ~/.pki/nssdb/ -L -n certificate_nickname 

Generate an RSA private key

$ certutil -d ~/.pki/nssdb/ -G -g keysize -n nickname 

Generate a certificate signing request

$ certutil -d ~/.pki/nssdb/ -R -k key-id -s subject -o file 

Generate a self-signed certificate

$ certutil -d ~/.pki/nssdb/ -S -s subject -n nickname -x -t C,C,C -o file 

Import certificate

To add a certificate specify the -A option:

$ certutil -d ~/.pki/nssdb/ -A -t "TRUSTARGS" -n certificate_nickname -i /path/to/cert/filename 

The TRUSTARGS are three strings of zero or more alphabetic characters, separated by commas, for example: «TCu,Cu,Tuw» . They define how the certificate should be trusted for SSL, email, and object signing, and are explained in the certutil documentation [dead link 2023-05-06 ⓘ] or Meena’s blog post on trust flags.

To add a personal certificate and private key for SSL client authentication use the command:

$ pk12util -d ~/.pki/nssdb/ -i /path/to/PKCS12/cert/filename.p12 

This will import a personal certificate and private key stored in a PKCS #12 file. The TRUSTARGS of the personal certificate will be set to «u,u,u» .

Edit certificate

Call certutil with -M option to edit the certificate. For example, to edit the TRUSTARGS :

$ certutil -d ~/.pki/nssdb/ -M -t "TRUSTARGS" -n certificate_nickname 

Delete certificate

Use -D option to remove the certificate:

$ certutil -d ~/.pki/nssdb/ -D -n certificate_nickname 

Adding a trusted CA certificate

A system-wide trust store /usr/lib/pkcs11/p11-kit-trust.so is usually automatically added to the list of PKCS #11 modules. See Transport Layer Security#Trust management for system-wide configuration. For application-specific configuration use such a command to add a CA certificate:

certutil -d ~/.pki/nssdb/ -A -i /path/to/certificate -n certificate nickname -t C,,

See also

Источник