selinux June 2006

selinux@lists.fedoraproject.org

45 participants
61 discussions

List of operations
by Göran Uddeborg 17 Oct '06

17 Oct '06

Maybe this is a FAQ, but I haven't found it answered in any of the FAQ:s I've looked through: Is there some kind of documentation list over the available classes and operations (permissions)? Other concepts, like types and roles are defined in the policy, with some luck together with a comment. In some cases there are even manual pages, like httpd_selinux. But the list of available classes and operations must be defined by the kernel module if I understand things correctly. I could extract a list from the flask/access_vectors file. But I would have liked something with a sentence or so of explanation. Some names may be self-explanatory, but many are not obvious. I'm imagining some kind of list like the appendices of the O'Reilley book, but updated for the current version. Does such a list exist somewhere? Or is it just in my imagination? :-)

4 4

Re: postfix, procmail and SELinux - No Go
by Paul Howarth 14 Aug '06

14 Aug '06

On Tue, 2006-06-06 at 21:34 -0500, Marc Schwartz wrote: > Paul, > > OK...seemingly back up and running. Here are the present avc messages > since re-loading everything and confirming that the file contexts are > back to the changes that we made. > > I note that the /proc/meminfo messages are back, but now for > clamassassin. I am sure that I have reloaded the new modules that we > created, so not sure what is up here, unless there was some conflict > when the two versions of the policies we seemingly loaded earlier today. > > Let me know on these and if perhaps I missed something: You forgot that we reverted the clamassassin context change yesterday. # restorecon -v /usr/local/bin/clamassassin > type=AVC msg=audit(1149646922.456:801): avc: denied { read } for pid=23273 comm="clamassassin" name="meminfo" dev=proc ino=-268435454 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > type=SYSCALL msg=audit(1149646922.456:801): arch=40000003 syscall=5 success=yes exit=3 a0=489093ef a1=0 a2=1b6 a3=a021240 items=1 pid=23273 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash" > type=CWD msg=audit(1149646922.456:801): cwd="/home/marcs" > type=PATH msg=audit(1149646922.456:801): item=0 name="/proc/meminfo" flags=101 inode=4026531842 dev=00:03 mode=0100444 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1149646922.456:802): avc: denied { getattr } for pid=23273 comm="clamassassin" name="meminfo" dev=proc ino=-268435454 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file > type=SYSCALL msg=audit(1149646922.456:802): arch=40000003 syscall=197 success=yes exit=0 a0=3 a1=bf8d7f28 a2=4891eff4 a3=3 items=0 pid=23273 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash"type=AVC_PATH msg=audit(1149646922.456:802): path="/proc/meminfo" > type=AVC msg=audit(1149646922.456:803): avc: denied { search } for pid=23273 comm="clamassassin" name="bin" dev=hdc7 ino=3112982 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir > type=SYSCALL msg=audit(1149646922.456:803): arch=40000003 syscall=5 success=yes exit=3 a0=a023018 a1=8000 a2=0 a3=8000 items=1 pid=23273 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamassassin" exe="/bin/bash" > type=CWD msg=audit(1149646922.456:803): cwd="/home/marcs" > type=PATH msg=audit(1149646922.456:803): item=0 name="/usr/local/bin/clamassassin" flags=101 inode=3115337 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1149646922.460:804): avc: denied { execute } for pid=23274 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=AVC msg=audit(1149646922.460:804): avc: denied { execute_no_trans } for pid=23274 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=AVC msg=audit(1149646922.460:804): avc: denied { read } for pid=23274 comm="clamassassin" name="mktemp" dev=hdc7 ino=1966111 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file > type=SYSCALL msg=audit(1149646922.460:804): arch=40000003 syscall=11 success=yes exit=0 a0=a0232c0 a1=a023500 a2=a026dd0 a3=a023228 items=2 pid=23274 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp" exe="/bin/mktemp" > type=AVC_PATH msg=audit(1149646922.460:804): path="/bin/mktemp" > type=AVC_PATH msg=audit(1149646922.460:804): path="/bin/mktemp" > type=CWD msg=audit(1149646922.460:804): cwd="/home/marcs" > type=PATH msg=audit(1149646922.460:804): item=0 name="/bin/mktemp" flags=101 inode=1966111 dev=16:07 mode=0100555 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1149646922.460:804): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1149646922.460:805): avc: denied { read } for pid=23274 comm="mktemp" name="urandom" dev=tmpfs ino=1719 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file > type=SYSCALL msg=audit(1149646922.460:805): arch=40000003 syscall=5 success=yes exit=3 a0=80494d8 a1=0 a2=48920120 a3=8f5f008 items=1 pid=23274 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="mktemp" exe="/bin/mktemp" > type=CWD msg=audit(1149646922.460:805): cwd="/home/marcs" > type=PATH msg=audit(1149646922.460:805): item=0 name="/dev/urandom" flags=101 inode=1719 dev=00:0f mode=020444 ouid=0 ogid=0 rdev=01:09 > type=AVC msg=audit(1149646922.468:806): avc: denied { execute_no_trans } for pid=23277 comm="clamassassin" name="clamscan" dev=hdc7 ino=3123838 scontext=system_u:system_r:clamscan_t:s0 tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1149646922.468:806): arch=40000003 syscall=11 success=yes exit=0 a0=a026c00 a1=a026210 a2=a026dd0 a3=a026d90 items=2 pid=23277 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="clamscan" exe="/usr/bin/clamscan" > type=AVC_PATH msg=audit(1149646922.468:806): path="/usr/bin/clamscan" > type=CWD msg=audit(1149646922.468:806): cwd="/home/marcs" > type=PATH msg=audit(1149646922.468:806): item=0 name="/usr/bin/clamscan" flags=101 inode=3123838 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1149646922.468:806): item=1 flags=101 inode=754491 dev=16:07 mode=0100755 ouid=0 ogid=0 rdev=00:00 The context change should fix all of the above. > type=AVC msg=audit(1149646926.516:807): avc: denied { recv_msg } for saddr=66.250.40.33 src=24441 daddr=192.168.1.2 dest=32875 netif=eth0 scontext=user_u:system_r:pyzor_t:s0 tcontext=system_u:object_r:pyzor_port_t:s0 tclass=udp_socket Hmm, pyzor needs to receive messages as well as send them... > type=AVC msg=audit(1149646926.528:808): avc: denied { create } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket > type=SYSCALL msg=audit(1149646926.528:808): arch=40000003 syscall=102 success=yes exit=3 a0=1 a1=bfb89868 a2=4891eff4 a3=8069fbf items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" > type=SOCKETCALL msg=audit(1149646926.528:808): nargs=3 a0=10 a1=3 a2=0 > type=AVC msg=audit(1149646926.528:809): avc: denied { bind } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket > type=SYSCALL msg=audit(1149646926.528:809): arch=40000003 syscall=102 success=yes exit=0 a0=2 a1=bfb89868 a2=4891eff4 a3=3 items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" > type=SOCKADDR msg=audit(1149646926.528:809): saddr=100000000000000000000000 > type=SOCKETCALL msg=audit(1149646926.528:809): nargs=3 a0=3 a1=bfb89874 a2=c > type=AVC msg=audit(1149646926.528:810): avc: denied { getattr } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket > type=SYSCALL msg=audit(1149646926.528:810): arch=40000003 syscall=102 success=yes exit=0 a0=6 a1=bfb89868 a2=4891eff4 a3=3 items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" > type=SOCKETCALL msg=audit(1149646926.528:810): nargs=3 a0=3 a1=bfb89874 a2=bfb89880 > type=AVC msg=audit(1149646926.528:811): avc: denied { write } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket > type=AVC msg=audit(1149646926.528:811): avc: denied { nlmsg_read } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket > type=SYSCALL msg=audit(1149646926.528:811): arch=40000003 syscall=102 success=yes exit=20 a0=b a1=bfb887b4 a2=4891eff4 a3=ffffffcc items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" > type=SOCKADDR msg=audit(1149646926.528:811): saddr=100000000000000000000000 > type=SOCKETCALL msg=audit(1149646926.528:811): nargs=6 a0=3 a1=bfb8982c a2=14 a3=0 a4=bfb89840 a5=c > type=AVC msg=audit(1149646926.528:812): avc: denied { read } for pid=23325 comm="dccproc" scontext=user_u:system_r:spamd_t:s0 tcontext=user_u:system_r:spamd_t:s0 tclass=netlink_route_socket > type=SYSCALL msg=audit(1149646926.528:812): arch=40000003 syscall=102 success=yes exit=128 a0=11 a1=bfb887b4 a2=4891eff4 a3=ffffffcc items=0 pid=23325 auid=500 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=0 sgid=500 fsgid=0 comm="dccproc" exe="/usr/local/bin/dccproc" > type=SOCKETCALL msg=audit(1149646926.528:812): nargs=3 a0=3 a1=bfb89810 a2=0 I've seen a lot of these recently. I think dcc is trying to read the routing table. We'll allow that. (snip) The rest seem to be duplicates. Updated policy modules: ####### mydcc.te ####### policy_module(mydcc, 0.1.3) require { type spamd_t; } type dcc_var_t; files_type(dcc_var_t) type dcc_client_map_t; files_type(dcc_client_map_t) # Allow spamd to behave as a dcc client allow spamd_t dcc_client_map_t:file rw_file_perms; allow spamd_t dcc_var_t:dir search; # Allow spamd to read the routing table (needed by dcc) allow spamd_t self:netlink_route_socket { r_netlink_socket_perms }; ####### mypyzor.te ####### policy_module(mypyzor, 0.1.3) require { type pyzor_t; type pyzor_port_t; type spamd_t; }; # temp files type pyzor_tmp_t; files_tmp_file(pyzor_tmp_t) # Allow pyzor to create and use temp files and dirs allow pyzor_t pyzor_tmp_t:dir create_dir_perms; allow pyzor_t pyzor_tmp_t:file create_file_perms; files_type(pyzor_tmp_t) files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir }) # Allow pyzor to read config (and any other file...) # from user home directories userdom_read_unpriv_users_home_content_files(pyzor_t) # Allow pyzor to read /dev/urandom dev_read_urand(pyzor_t) # Allow pyzor to send and receive pyzor messages! allow pyzor_t pyzor_port_t:udp_socket send_msg; allow pyzor_t pyzor_port_t:udp_socket recv_msg; # Allow spamd to signal pyzor (kill/hup ?) allow spamd_t pyzor_t:process signal; # Allow pyzor to ...? corecmd_search_bin(pyzor_t) kernel_read_kernel_sysctls(pyzor_t) # It does a getattr on /usr/bin/time for reasons unknown... allow pyzor_t bin_t:dir getattr; allow pyzor_t bin_t:file getattr; # Pyzor/python probably doesn't need to be able to read /proc/meminfo kernel_dontaudit_list_proc(pyzor_t) kernel_dontaudit_read_system_state(pyzor_t) Paul.

8 104

FC2 useradd in chroot on FC5 host with SELinux
by Paul Howarth 11 Aug '06

11 Aug '06

I use mock to build packages for old distributions in a chroot-ed environment on my FC5 box. I've pretty well got this working for all old distributions now apart from FC2 (see http://www.fedoraproject.org/wiki/Legacy/Mock). On FC2, the process gets off to quite a good start, installing the following packages into the chroot: ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: buildsys-build noarch 0.5-1.CF.fc2 groups 1.8 k Installing for dependencies: SysVinit i386 2.85-25 core 96 k basesystem noarch 8.0-3 core 2.7 k bash i386 2.05b-38 core 1.5 M beecrypt i386 3.1.0-3 core 64 k binutils i386 2.15.90.0.3-5 core 2.8 M buildsys-macros noarch 2-2.fc2 groups 2.1 k bzip2 i386 1.0.2-12.1 core 48 k bzip2-libs i386 1.0.2-12.1 core 32 k chkconfig i386 1.3.9-1.1 core 99 k coreutils i386 5.2.1-7 core 2.8 M cpio i386 2.5-6 core 45 k cpp i386 3.3.3-7 core 1.4 M cracklib i386 2.7-27.1 core 26 k cracklib-dicts i386 2.7-27.1 core 409 k db4 i386 4.2.52-3.1 core 1.5 M dev i386 3.3.13-1 core 3.6 M diffutils i386 2.8.1-11 core 205 k e2fsprogs i386 1.35-7.1 core 728 k elfutils-libelf i386 0.95-2 core 36 k ethtool i386 1.8-3.1 core 48 k fedora-release i386 2-4 core 92 k file i386 4.07-4 core 242 k filesystem i386 2.2.4-1 core 18 k findutils i386 1:4.1.7-25 core 102 k gawk i386 3.1.3-7 core 1.5 M gcc i386 3.3.3-7 core 3.8 M gcc-c++ i386 3.3.3-7 core 2.0 M gdbm i386 1.8.0-22.1 core 26 k glib i386 1:1.2.10-12.1.1 core 134 k glib2 i386 2.4.8-1.fc2 updates-released 477 k glibc i686 2.3.3-27.1 updates-released 4.9 M glibc-common i386 2.3.3-27.1 updates-released 14 M glibc-devel i386 2.3.3-27.1 updates-released 1.9 M glibc-headers i386 2.3.3-27.1 updates-released 530 k glibc-kernheaders i386 2.4-8.44 core 697 k grep i386 2.5.1-26 core 168 k gzip i386 1.3.3-12.2.legacy updates-released 88 k info i386 4.7-4 updates-released 147 k initscripts i386 7.55.2-1 updates-released 906 k iproute i386 2.4.7-14 core 591 k iputils i386 20020927-13 core 92 k less i386 382-3 core 85 k libacl i386 2.2.7-5 core 15 k libattr i386 2.4.1-4 core 8.6 k libgcc i386 3.3.3-7 core 33 k libselinux i386 1.11.4-1 core 45 k libstdc++ i386 3.3.3-7 core 240 k libstdc++-devel i386 3.3.3-7 core 1.3 M libtermcap i386 2.0.8-38 core 12 k make i386 1:3.80-3 core 337 k mingetty i386 1.07-2 core 18 k mktemp i386 2:1.5-7 core 12 k modutils i386 2.4.26-16 core 395 k ncurses i386 5.4-5 core 1.5 M net-tools i386 1.60-25.1 updates-released 311 k pam i386 0.77-40 core 1.9 M patch i386 2.5.4-19 core 61 k pcre i386 4.5-2 core 59 k perl i386 3:5.8.3-18 core 11 M perl-Filter i386 1.30-5 core 68 k popt i386 1.9.1-0.4.1 updates-released 61 k procps i386 3.2.0-1.2 updates-released 176 k psmisc i386 21.4-2 core 41 k redhat-rpm-config noarch 8.0.28-1.1.1 core 41 k rpm i386 4.3.1-0.4.1 updates-released 2.2 M rpm-build i386 4.3.1-0.4.1 updates-released 437 k sed i386 4.0.8-4 core 116 k setup noarch 2.5.33-1 core 29 k shadow-utils i386 2:4.0.3-55 updates-released 671 k sysklogd i386 1.4.1-16 core 65 k tar i386 1.13.25-14 core 351 k termcap noarch 11.0.1-18.1 core 237 k tzdata noarch 2005f-1.fc2 updates-released 449 k unzip i386 5.50-37 core 139 k util-linux i386 2.12-19 updates-released 1.5 M which i386 2.16-2 core 21 k words noarch 2-22 core 137 k zlib i386 1.2.1.2-0.fc2 updates-released 44 k After installing all of these packages successfully, the next thing that happens is: Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-2-i386-core/root /bin/su - root -c "/usr/sbin/useradd -m -u 500 -d /builddir mockbuild" and at that point the "useradd" process just hangs indefinitely. I'm told that if SELinux is disabled (I've tried permissive mode and that doesn't help), this works. I can't see any AVCs in the logs. Any ideas what might be causing this and how it might be fixed? Paul.

3 15

Running two named processes in selinux
by Faisal Ali 13 Jul '06

13 Jul '06

Hi, Is it possible to run two named process in selinux each having different file permissions. Instead of using DNS Views Iam thinking about running two named processes, one for external and one for internal. Ofcourse external named process will have access to different set of files versus internal named process. Can this be done. Its security-of-Xen-Vm-isolation vs SELinux-isolation comparision. Should I run two Xen VMs one for external DNS and the other for Internal DNS or run two named processes each isolated and jailed by SELinux. Faisal Ali

2 1

pam_console_t wants access to device_t:chr_file ?
by Tom London 13 Jul '06

13 Jul '06

Running targeted/enforcing, latest Rawhide. Noticed this in /var/log/messages, before auditd is started I guess: Jun 29 06:43:48 localhost kernel: audit(1151588567.562:102): avc: denied { getattr } for pid=1526 comm="pam_console_app" name="usbdev5.5_ep02" dev=tmpfs ino=5143 scontext=system_u:system_r:pam_console_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file Jun 29 06:43:48 localhost kernel: audit(1151588567.562:103): avc: denied { getattr } for pid=1526 comm="pam_console_app" name="usbdev5.5_ep81" dev=tmpfs ino=5120 scontext=system_u:system_r:pam_console_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file Jun 29 06:43:48 localhost kernel: audit(1151588567.562:104): avc: denied { getattr } for pid=1526 comm="pam_console_app" name="usbdev5.5_ep00" dev=tmpfs ino=5068 scontext=system_u:system_r:pam_console_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file << actually many, many copies of these....>> tom -- Tom London

3 7

dovecot 1.0.rc1
by Paul Howarth 13 Jul '06

13 Jul '06

New in rc1 is a directory /var/lib/dovecot where the SSL parameters files are generated before they are copied to the login directory. The following additions to policy support this: :::::::::::::: dovecot.fc :::::::::::::: /var/lib/dovecot(/.*)? gen_context(system_u:object_r:dovecot_var_lib_t,s0) :::::::::::::: dovecot.te :::::::::::::: policy_module(dovecot, 0.1.4) ######################################## # # Declarations # require { type dovecot_t; }; # /var/lib/dovecot holds SSL parameters file type dovecot_var_lib_t; files_type(dovecot_var_lib_t) ######################################## # # Local policy # # Allow dovecot to read the routing table (in selinux-policy 2.2.43-4.fc5) #allow dovecot_t self:netlink_route_socket { r_netlink_socket_perms }; # Allow dovecot to create and read SSL parameters file files_search_var_lib(dovecot_t) allow dovecot_t dovecot_var_lib_t:dir { rw_dir_perms }; allow dovecot_t dovecot_var_lib_t:file { manage_file_perms }; Paul.

2 1

AVCs when printing from firefox...
by Tom London 13 Jul '06

13 Jul '06

Running targeted/enforcing, latest rawhide. Trying to print from firefox, I get: type=AVC msg=audit(1151341517.216:697): avc: denied { recv } for pid=2965 comm="firefox-bin" saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151341520.217:698): avc: denied { recv } for saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151341526.217:699): avc: denied { recv } for saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151341538.217:700): avc: denied { recv } for saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151341562.219:701): avc: denied { recv } for saddr=127.0.0.1 src=50209 daddr=127.0.0.1 dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet Doing a 'setenforce 0' and retrying yields: type=AVC msg=audit(1151342357.528:780): avc: denied { recv } for pid=3943 comm="firefox-bin" saddr=127.0.0.1 src=47782 daddr=127.0.0.1 dest=631 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151342357.528:780): avc: denied { send } for pid=3943 comm="firefox-bin" saddr=127.0.0.1 src=631 daddr=127.0.0.1 dest=47782 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=SYSCALL msg=audit(1151342357.528:780): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bfbf8db0 a2=4703c3f4 a3=0 items=0 ppid=3938 pid=3943 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="firefox-bin" exe="/usr/lib/firefox-1.5.0.4/firefox-bin" subj=user_u:system_r:unconfined_t:s0 type=SOCKADDR msg=audit(1151342357.528:780): saddr=020002777F0000010000000000000000 type=SOCKETCALL msg=audit(1151342357.528:780): nargs=3 a0=27 a1=b6d875c a2=10 type=AVC msg=audit(1151342370.197:781): avc: denied { send } for pid=4108 comm="hp" saddr=127.0.0.1 src=43162 daddr=127.0.0.1 dest=50000 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151342370.197:781): avc: denied { recv } for pid=4108 comm="hp" saddr=127.0.0.1 src=43162 daddr=127.0.0.1 dest=50000 netif=lo scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151342370.197:781): avc: denied { send } for pid=4108 comm="hp" saddr=127.0.0.1 src=50000 daddr=127.0.0.1 dest=43162 netif=lo scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=AVC msg=audit(1151342370.197:781): avc: denied { recv } for pid=4108 comm="hp" saddr=127.0.0.1 src=50000 daddr=127.0.0.1 dest=43162 netif=lo scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:object_r:unlabeled_t:s0 tclass=packet type=SYSCALL msg=audit(1151342370.197:781): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bf86ac50 a2=804d110 a3=804d1a4 items=0 ppid=2246 pid=4108 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) comm="hp" exe="/usr/lib/cups/backend/hp" subj=system_u:system_r:cupsd_t:s0-s0:c0.c255 type=SOCKADDR msg=audit(1151342370.197:781): saddr=0200C3507F0000010000000000000000 type=SOCKETCALL msg=audit(1151342370.197:781): nargs=3 a0=4 a1=bf86ac78 a2=10 tom -- Tom London

3 2

Openswan on FC4/5
by Stuart James 13 Jul '06

13 Jul '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We are using Openswan to connect two of our sites together via an IPSEC tunnel. Recently we upgraded from FC3 to FC5 on our frontend firewalls, including the version of openswan , selinux policy, kernel ,ect. We used to run in enforcing mode without any difficulties, it now seems that with Enforcing mode on Openswan does not seem to be able to add the route. Using setenforce 0 , the tunnel becomes active. As far as i can tell Openswan has difficulty adding the route to the Right/Left nexthop, although the status of the tunnel appears to be up, the routing does not appear to take place. #audit2allow -a -t /var/log/audit/audit.log allow ifconfig_t self:netlink_xfrm_socket create; allow ifconfig_t initrc_t:unix_stream_socket { read write }; Versions we are using are. selinux-policy-targeted-2.2.43-4.fc5 kernel-2.6.16-1.2122_FC5 openswan-2.4.4-1.1.2.1 As i have not seen any other mention of this being an issue, I was wondering if anyone else has encountered this. I have also tested this on FC4 with the same result. Am i right in assuming that openswan is using ifconfig to add the route, i have looked into the source policy that define ipsec which has no reference to ifconfig, but rather to ipsec eroute. I am not sure if this just defined in the wrong place, or if it needs ifconfig to be added into the policy. Regards, Stuart James -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEn5lKr8LwOCpshrYRAr+gAJ9y7uL7WOco3Pxj4gg0gWlrqhGRIQCeLIFu Cfnub95XnvCsMRwxI9ojSek= =dXrv -----END PGP SIGNATURE-----

2 4

RE: Running two named processes in selinux
by Paul Howarth 30 Jun '06

30 Jun '06

On Fri, 2006-06-30 at 16:15 -0400, Faisal Ali wrote: > Yes, exactly to run named in different SELinux domains. Iam glad its doable, > do you mean use the canned policy for one named and create a new one for > another named process. Can you point me to any read on the web that can help > in doing this. Can't think of any offhand. The approach I'd take would be to get the SELinux SRPM and "prep" it to get all the patches applied, then find the bind policy module and make a copy of it, and then edit all of the named_* types to have another name (e.g. other_named_*). Change the file contexts to refer to the locations and new type names you're using, then try building and loading the new module and see how it goes. Of course, I'd get the two-daemon thing working without SELinux (or with the same policy for each) first. > I guess its more of comfort level thing, I know BIND9 is quite secure and I > have'nt heard of any hacks. But if it happens then hacker can have > visibility to internal hosts information. True, but is that such a big deal? It might give a clue to where to start looking for targets but if they can get into your network they could probably figure that out anyway by portscanning. Paul.

1 0

Running two named processes in selinux
by Faisal Ali 30 Jun '06

30 Jun '06

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux June 2006