Sl

Материал из ALT Linux Wiki

Версия 10: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

Разбор:

1. getpeercon_server работает как s3:c3-s15:c0.c31
   
2. nc работает как s4:c4-s15:c0.c31
   
3. трафик от s4:c4-s15:c0.c31 получается s4:c4
   
4. tcontext=generic_u:object_r:unlabeled:s0 - SYN, SYN+ACK (видимо, от ядра, поэтому s0)
5. tclass == peer относится только к классу трафика
6. define(`all_peer_perms',`{ recv }') - у этого класса (трафика) есть только один метод recv
7. в сокет scontext=officer_u:generic_r:generic_t:s4:c4 припёрся пакет с tcontext=generic_u:object_r:unlabeled:s4:c4
8. получается, что где-то в районе accept новому сокету назначается контекст в соответствии с тем, кто туда пришёл. Cубъект тут — именно сокет, поскольку пакет кладётся в буфер сокета, а какой именно процесс потом его оттуда будет брать, неизвестно.
9. сокет - можно и другому процессу передать. смысл в том, что читать из сокета может совсем не тот процесс, который его создавал.
10. при системном вызове проверка SOCKET__READ, и вот тут уже субъектом будет процесс, а объектом — сокет
11. sid нового сокета делается через security_sid_mls_copy(sksec->sid, peersid, &newsid);
12. без CIPSO у тебя peersid не приедет с другого конца
13. security_sid_mls_copy() - computes a new sid based on the given * sid and the mls portion of mls_sid.
14. вот так у сокета и получается s4:c4, поскольку оно из пакета приходит
15. s3:c3 создал себе сокет, в него пришел трафик, и сокет стал == уровню трафика который туда попал.

 вот нашёл место, где sock->sk->sk_security->sid всё-таки попадает в SOCK_INODE(sock)->i_security->sid
 selinux_sock_graft
 вызывается из inet_accept
 так что по идее в проверках read для socket можно ловить приём не тем процессом, каким надо с учётом изменения уровня сокета