No xattr hash found astra linux

Using xattrs or Extended Attributes on Linux

Extended attributes or xattrs, are an extensible mechanism to store metadata on a filesystem. Metadata is a collection of information or data points about a particular object. If we would compare this article, the metadata contains the title, author, description, language, Twitter image, etc.

Normally the file system can only store a limited set of information about files. Typically this is the filename, ownership, file permissions, and dates. By using extended attributes, we can describe more properties of the file.

Support for extended attributes

Not all file systems have support for xattrs. However, the popular ones do, like EXT4, Btrfs, ReiserFS, JFS, and ZFS. To determine if your file system has xattr support enabled, check the options file of the related device:

# cat /proc/fs/ext4/sda1/options | grep xattr user_xattr

One way to set an attribute for a file is by adding an access control list (ACL). This can be done with the setfacl command. For example, we can allow the web server daemon to read data from /data/storage.

# setfacl -m u:www-data:r /data/storage

Running the command won’t give any output. So let’s check if something has changed:

# ls -l
total 4
drwxr-xr-x+ 2 root root 4096 Nov 18 16:00 storage

The plus sign in ls reveals there is something different than the other files. This is because of adding the extended attribute.

Although we could use the getfacl command to determine the permissions, we can actually use the getfattr command to see what kind of attribute is added.

# getfattr /data/storage

getfattr: Removing leading ‘/’ from absolute path names
# file: data/storage
system.posix_acl_access

Now we know for sure it is an ACL stored in the extended attributes of this particular file (or actually directory).

If we want to see detailed information, we can use the xattr tool for that.

Using xattr to list extended attributes of a file

Other attributes

security.capability

The security.capability files stores Linux capabilities for the related file. Applies to binaries which are provided one or more capabilities via this file.

security.ima

For the Integrity Measurement Architecture (IMA), the file security.ima stores a hash or digital signature.

security.evm

Similar to security.ima, the Extended Verification Module (EVM) stores a hash/HMAC or digital signature in this file. The different with IMA is that it protects the metadata of the file, not the contents.

Related tools

getfacl

Installation: apt-get install acl

getfattr

Installation: apt-get install attr

xattr

Installation: apt-get install python-xattr

More resources

Two useful links suggested by our readers, are:

One more thing.

Keep learning

So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert.

Security scanning with Lynis and Lynis Enterprise

Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance.

Источник

Смоленск 1.6 Проблема с подписью приложения для замкнутой программной среды

Ключ был сгенерирован командой: gpg —full-generate-key
Параметры указанные при генерации: GOST R.34.10-2012 (sign only), без ограничения срока ключа, без пароля.
Подпись производилась командой: bsign -N -s —pgoptions=»—batch —pinentry-mode=loopback —default-key=36ABE65F5F51F5BD» a.out

version: 1
id: bsign v1.0
hash: e9999506323ea6a9cf142e643202497fff072d8b793f6c286fd95659fda73b9c
signature_size: 119
signature:
88 75 04 00 23 0c 00 1d 16 21 04 e2 00 4b 1d 33
4e 71 c6 7b aa 30 f9 36 ab e6 5f 5f 51 f5 bd 05
02 5c 50 46 0e 00 0a 09 10 36 ab e6 5f 5f 51 f5
bd 78 a0 00 fd 16 1d f3 b4 1b 22 45 c9 88 3b 53
5e 22 ab bd d5 e3 cb df c6 8f 26 91 95 f8 92 2c
4d ad 74 b1 2a 00 ff 71 ae 0e 17 b2 78 62 43 70
e1 a9 eb 54 c9 5a 83 23 be e0 b8 32 43 db dc ca
02 bd f3 2a 14 96 22
signer: 36ABE65F5F51F5BD
timestamp: 29 Jan 2019 15:24:46 (1548764686)
bsign: good hash found in ‘a.out’.
version: 1
xattr hash: 0f923b3e34dab3d7f30e81545ce1aaaf95100056a35cf48ad13e654bd9547622
xattr signature_size: 119
xattr signature:
88 75 04 00 23 0c 00 1d 16 21 04 e2 00 4b 1d 33
4e 71 c6 7b aa 30 f9 36 ab e6 5f 5f 51 f5 bd 05
02 5c 50 46 0e 00 0a 09 10 36 ab e6 5f 5f 51 f5
bd 6e e9 00 ff 4b 1a 26 a3 5d 1c 9e 16 30 5d 21
57 2e 3d 87 38 c5 2f 85 74 48 5d 93 07 f0 1d ce
24 b8 c3 ab 41 00 f9 01 92 c4 83 78 f6 fb 7b 90
52 dc 44 0e 82 ed 1f 6c ce 72 ce 40 5b 14 4e d7
d8 1f 16 77 72 71 4b
signer: 36ABE65F5F51F5BD
timestamp: 29 Jan 2019 15:24:46 (1548764686)
bsign: good xattr hash found in ‘a.out’.

Команда gpg —list-secret-keys показывают наличие секретного ключа.
Публичный ключ был дополнительно экспортирован в файл с помощью команды: gpg —export -a «User Name» > publickey.gpg и помещен в каталог /etc/digsig/keys.
Также была выполнена команда для обновления initramfs update-initramfs -u -t -k all и перезагружена система.
При старте системы ключ /etc/digsig/keys/publickey.gpg был загружен.
Прошу подсказать возможное решение данной проблемы.

Источник

Как восстановить доступ к зашифрованному разделу?

Шолом. Есть образ диска, снятый dd-шкой с жёсткого диска. На диске был запароленный раздел LUKS с информацией, который в один прекрасный момент перестал определяться и стал монтироваться как раздел ext4. Можно как-то вернуть статус кво? На диск ничего не писалось.

Чем заканчивается попытка смонтировать контейнер через cryptsetup luksOpen?
Может в дистрибутиве банально поломали правила udev, вот и определяется как попало.

// Задумался над бекапом заголовков контейнеров в /boot

Чуть-чуть подробностей, pls.

Диск открывается, но файлов в нём нет.

Диск открывается, но файлов в нём нет.

Я имею в виду «Открывается как ext4», конечно.

Ни фига не понятно.
Обычно схема такая:
Диск > Раздел LUKS > LVM > Том LV > ФС
У вас как было?

Чуть-чуть подробностей, pls.
Диск открывается, но файлов в нём нет.

Когда у вас в какой-то юзерспейсной программе диск «открывается», то за кулисами udev пытается решить что это такое и с чем его жевать.

Тот раздел, который у вас теперь определяется как ext4, попробуйте напрямую смонтировать как LUKS контейнер: cryptsetup luksOpen /dev/sdX test
Если заголовки целы, то у вас спросят пароль и появится блочное устройство /dev/mapper/test, которое уже можно монтировать модулем файловой системы, которая была в контейнере.

Я создавал раздел через GNOME Disks, на диске создавался зашифрованный LUKS, а уже в нём — раздел ext4.

Device /dev/loop0 is not a valid LUKS device.

Чуть-чуть подробностей — под LUKS был выделен отдельный жёсткий диск, подключавшийся через док-станцию. Возможно, я выключил её, не отмонтировав и не остановив шпиндель (вообще так не делаю, но мог забыть). Вот заголовки и послетали.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

parted /path/to/dump.img print kpartx -l /path/to/dump.img 

Модель: (file) Диск /run/media/zoominger/XFS/Образы дисков/Образы жёстких дисков/Док-станция.img: 251GB Размер сектора (логич./физич.): 512B/512B Таблица разделов: loop Флаги диска: Номер Начало Конец Размер Файловая система Флаги 1 0,00B 251GB 251GB ext2 

Похоже, что полетела разметка.
При условии, что образ сняли правильно со всего диска.
Дальше наверно надо копать в сторону TestDisk.

Кажется, testdisk пробовал, не помню, давно это было. Сейчас ещё раз попробую, отпишусь о результатах.

Кстати, вот ещё такая странность — на диске, у папке lost and found безумное количество папок и каких-то файлов:

drwxr-xr-x 0 0 4096 15-Feb-2015 09:57 #3014919 drwxr-xr-x 0 0 4096 15-Feb-2015 09:57 #3014929 drwxr-xr-x 0 0 4096 15-Feb-2015 09:57 #3014930 drwxr-xr-x 0 0 4096 15-Feb-2015 09:57 #3014931 d——x— 48501 30337 4096 7-Dec-2065 15:01 #4411000 dr-x—s-wt 34940 60724 4096 10-Dec-2091 01:11 #6405022 dr-srwxr-T 18596 45820 4096 13-Mar-2042 09:57 #6995469 d-wxrws-wt 23780 20159 4096 23-Jan-2015 20:48 #12181050 dr-S—srwx 34335 23161 4096 21-Jun-2105 07:19 #13255122 p—x—sr-T 19883 14610 0 18-Dec-2058 17:29 #35 srwxr-Sr-T 53200 14611 0 24-Jul-2092 01:48 #38 b—S-wS— 20209 64620 0 27-Sep-2007 11:35 #93 crw-r-Sr-T 12558 3963 0 23-May-1970 06:21 #112 p—rwxrw- 55129 65049 0 3-May-2060 12:07 #124 pr-xr-Srwx 42591 14213 0 4-Oct-2103 15:33 #143 b-ws——T 42523 29751 0 26-Nov-2098 13:15 #156 c—xr-xr— 27753 14060 0 26-Jul-2062 17:34 #184 p-wx—xrwx 57932 62577 0 22-Apr-2063 21:28 #193 cr-x—S—t 21963 55267 0 11-Sep-2049 16:56 #196 b—s-w-rwx 20861 24191 0 13-Jul-2051 18:05 #214

brwx-wS—T 62094 46245 0 10-Jul-2008 14:17 #227

Device /dev/loop0 is not a valid LUKS device.

Похоже заголовки действительно всё.

Чуть-чуть подробностей — под LUKS был выделен отдельный жёсткий диск, подключавшийся через док-станцию. Возможно, я выключил её, не отмонтировав и не остановив шпиндель (вообще так не делаю, но мог забыть). Вот заголовки и послетали.

У меня когда материнская плата умирала, то LUKS на четырёх HDD пережил целую кучу хардлоков без последствий. Возможно вам сильно не повезло.

Можно ли что-то сделать с LUKS разделом с мёртвыми заголовками я не знаю, но в целом LUKS — это что-то вроде обёртки, по идее зная параметры шифрования и смещение шифрованного контейнера всё ещё можно его как-то расшифровать.
Я бы копал в этом направлении.

Детект как ext4 не очень мне нравится. Возможно ли, что винт действительно был по ошибке отформатирован?
Если выполнить tune2fs -l loop0, что говорит?

на диске, у папке lost and found безумное количество папок и каких-то файлов

Возможно, какие-то из файлов уцелели, но их имена побились.
Если там было что-то ценное, можно попробовать выковырять по типу файла через find+file/foremost или по содержимому через grep.

Детект как ext4 не очень мне нравится. Возможно ли, что винт действительно был по ошибке отформатирован?

Мне тоже не нравится. Всегда включал док-станцию, появлялось окно ввода пароля, сначала для LUKS, потом для монтирования. В один прекрасный день потребовался только пароль на монтирование; файловая система стала ext4 и была совершенно пустой. Это-то меня и удивляет — ни с того ни с сего исчез раздел.

А я и копал 🙂 Есть два совершенно одинаковых диска (один из них был с LUKS), я создавал на втором такую же ФС и переносил заголовки и прочее с него на первый диск. К сожалению, не помогало.

tune2fs 1.42.13 (17-May-2015) Filesystem volume name: HDD2 Last mounted on: Filesystem UUID: 1f2bd7c7-250b-46c1-a265-6549e8cb913d Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 15327232 Block count: 61279056 Reserved block count: 3063952 Free blocks: 60195647 Free inodes: 14370782 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1009 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Mon Feb 16 18:33:58 2015 Last mount time: Fri Apr 10 18:02:51 2015 Last write time: Fri Apr 10 18:14:04 2015 Mount count: 3 Maximum mount count: -1 Last checked: Fri Apr 10 17:54:17 2015 Check interval: 0 () Lifetime writes: 34 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Default directory hash: half_md4 Directory Hash Seed: 2caec387-799f-44fd-8a96-cc887a006b45 Journal backup: inode blocks

Источник