Sl: различия между версиями
Нет описания правки |
Stanv (обсуждение | вклад) Нет описания правки |
||
Строка 61: | Строка 61: | ||
systemd-journald - выполняется в домене trusted_t. Это обусловленно тем, что ему необходимо читать статус процессов из /proc/<PID>. | systemd-journald - выполняется в домене trusted_t. Это обусловленно тем, что ему необходимо читать статус процессов из /proc/<PID>. | ||
В свою очередь, proc-файлы для каждого процесса имеют контекст процесса. | В свою очередь, proc-файлы для каждого процесса имеют контекст процесса. | ||
== Network == | |||
Одна TCP транзакция для | |||
<code>auditallow unconfineddomain file_type:{ peer } recv;</code> | |||
# ./getpeercon_server 777 | |||
-> running as officer_u:generic_r:generic_t:s3:c3-s15:c0.c31 | |||
-> creating socket ... ok | |||
-> listening on TCP port 777 ... ok | |||
-> waiting ... | |||
Посылает сообщение nc из s4:c4 | |||
# echo 'Hello world!' | nc localhost 777 | |||
выглядит следующим образом: | |||
granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s3:c3-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=777 daddr=127.0.0.1 dest=58387 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s0 tclass=peer | |||
granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s3:c3-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
granted { recv } for pid=9867 comm="gs" saddr=127.0.0.1 src=777 daddr=127.0.0.1 dest=58387 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
granted { recv } for pid=9867 comm="gs" saddr=127.0.0.1 src=777 daddr=127.0.0.1 dest=58387 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
granted { recv } for pid=9867 comm="gs" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer | |||
Разбор: | |||
# getpeercon_server работает как s3:c3-s15:c0.c31<br\> | |||
# nc работает как s4:c4-s15:c0.c31<br\> | |||
# трафик от s4:c4-s15:c0.c31 получается s4:c4<br\> | |||
# tcontext=generic_u:object_r:unlabeled:s0 - SYN, SYN+ACK (видимо, от ядра, поэтому s0) | |||
# tclass == peer относится только к классу трафика | |||
# define(`all_peer_perms',`{ recv }') - у этого класса (трафика) есть только один метод recv | |||
# в сокет scontext=officer_u:generic_r:generic_t:s4:c4 припёрся пакет с tcontext=generic_u:object_r:unlabeled:s4:c4 | |||
# получается, что где-то в районе accept новому сокету назначается контекст в соответствии с тем, кто туда пришёл. Cубъект тут — именно сокет, поскольку пакет кладётся в буфер сокета, а какой именно процесс потом его оттуда будет брать, неизвестно. | |||
# сокет - можно и другому процессу передать. смысл в том, что читать из сокета может совсем не тот процесс, который его создавал. | |||
# при системном вызове проверка SOCKET__READ, и вот тут уже субъектом будет процесс, а объектом — сокет | |||
# sid нового сокета делается через security_sid_mls_copy(sksec->sid, peersid, &newsid); | |||
# без CIPSO у тебя peersid не приедет с другого конца | |||
# security_sid_mls_copy() - computes a new sid based on the given * sid and the mls portion of mls_sid. | |||
# вот так у сокета и получается s4:c4, поскольку оно из пакета приходит | |||
# s3:c3 создал себе сокет, в него пришел трафик, и сокет стал == уровню трафика который туда попал. | |||
вот нашёл место, где sock->sk->sk_security->sid всё-таки попадает в SOCK_INODE(sock)->i_security->sid | |||
selinux_sock_graft | |||
вызывается из inet_accept | |||
так что по идее в проверках read для socket можно ловить приём не тем процессом, каким надо с учётом изменения уровня сокета | |||
[[Категория:Features]] | [[Категория:Features]] | ||
[[Категория:Admin]] | [[Категория:Admin]] | ||
{{Category navigation|title=Features|category=Features|sortkey={{SUBPAGENAME}}}} | {{Category navigation|title=Features|category=Features|sortkey={{SUBPAGENAME}}}} |
Версия от 13:36, 2 июля 2013
Howto get working SeLinux AltLinux policy
Install policy
Install package selinux-policy-altlinux
Update Grub config
Update configuration GRUB's file: /etc/sysconfig/grub2:
GRUB_CMDLINE_LINUX_DEFAULT='panic=30 quiet splash security=selinux selinux=1'
It is also possible to add:
- enforcing=1
- log_buf_len=1M
grub-mkconfig > /boot/grub/grub.cfg
PAM configuration
- Add to /etc/pam.d/newrole before pam_namespace.so module
session required pam_exec.so debug /etc/security/alt.newrole/helper /etc/security/alt.newrole/config
- Add to /etc/pam.d/common-login:
# The first `session' module # pam_selinux.so close should be the first session rule session required pam_selinux.so close
# The last `session' module # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open verbose
ALT Linux aspects
newrole modifications
Add patch for policycoreutils-newrole has patch, that adds to Linux capabilities: CAP_SETGID & CAP_AUDIT_WRITE. For more info look up at: http://git.altlinux.org/gears/p/policycoreutils.git
Users
When system's users login the __default__ rule takes action. This rule says that:
- all system users are mapped to generic_u SeLinux user.
- all OS users has access only to s0 level.
# semanage login -l Login Name SELinux User MLS/MCS Range __default__ generic_u s0 root officer_u s0-s5:c0.c15
Add for specfic user:
# semanage login -a -s generic_u -r s0-s3:c2.c14 stanv
Policy's internals
systemd
systemd-journald - выполняется в домене trusted_t. Это обусловленно тем, что ему необходимо читать статус процессов из /proc/<PID>. В свою очередь, proc-файлы для каждого процесса имеют контекст процесса.
Network
Одна TCP транзакция для
auditallow unconfineddomain file_type:{ peer } recv;
# ./getpeercon_server 777 -> running as officer_u:generic_r:generic_t:s3:c3-s15:c0.c31 -> creating socket ... ok -> listening on TCP port 777 ... ok -> waiting ...
Посылает сообщение nc из s4:c4
# echo 'Hello world!' | nc localhost 777
выглядит следующим образом:
granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s3:c3-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=777 daddr=127.0.0.1 dest=58387 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s0 tclass=peer granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s3:c3-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer granted { recv } for pid=9867 comm="gs" saddr=127.0.0.1 src=777 daddr=127.0.0.1 dest=58387 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer granted { recv } for pid=9879 comm="nc" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer granted { recv } for pid=9867 comm="gs" saddr=127.0.0.1 src=777 daddr=127.0.0.1 dest=58387 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4-s15:c0.c31 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer granted { recv } for pid=9867 comm="gs" saddr=127.0.0.1 src=58387 daddr=127.0.0.1 dest=777 netif=lo scontext=officer_u:generic_r:generic_t:s4:c4 tcontext=generic_u:object_r:unlabeled:s4:c4 tclass=peer
Разбор:
- getpeercon_server работает как s3:c3-s15:c0.c31<br\>
- nc работает как s4:c4-s15:c0.c31<br\>
- трафик от s4:c4-s15:c0.c31 получается s4:c4<br\>
- tcontext=generic_u:object_r:unlabeled:s0 - SYN, SYN+ACK (видимо, от ядра, поэтому s0)
- tclass == peer относится только к классу трафика
- define(`all_peer_perms',`{ recv }') - у этого класса (трафика) есть только один метод recv
- в сокет scontext=officer_u:generic_r:generic_t:s4:c4 припёрся пакет с tcontext=generic_u:object_r:unlabeled:s4:c4
- получается, что где-то в районе accept новому сокету назначается контекст в соответствии с тем, кто туда пришёл. Cубъект тут — именно сокет, поскольку пакет кладётся в буфер сокета, а какой именно процесс потом его оттуда будет брать, неизвестно.
- сокет - можно и другому процессу передать. смысл в том, что читать из сокета может совсем не тот процесс, который его создавал.
- при системном вызове проверка SOCKET__READ, и вот тут уже субъектом будет процесс, а объектом — сокет
- sid нового сокета делается через security_sid_mls_copy(sksec->sid, peersid, &newsid);
- без CIPSO у тебя peersid не приедет с другого конца
- security_sid_mls_copy() - computes a new sid based on the given * sid and the mls portion of mls_sid.
- вот так у сокета и получается s4:c4, поскольку оно из пакета приходит
- s3:c3 создал себе сокет, в него пришел трафик, и сокет стал == уровню трафика который туда попал.
вот нашёл место, где sock->sk->sk_security->sid всё-таки попадает в SOCK_INODE(sock)->i_security->sid selinux_sock_graft вызывается из inet_accept так что по идее в проверках read для socket можно ловить приём не тем процессом, каким надо с учётом изменения уровня сокета