selinux September 2004

selinux@lists.fedoraproject.org

38 participants
57 discussions

AVCs with ntpd
by Felipe Alfaro Solana 22 Sep '04

22 Sep '04

OK, so I'm trying SElinux after having it disabled for some time. That's what I did: 1. Installed selinux-policy-targeted-1.17.16-2 2. Recompiled the kernel with SElinux support 3. Booted into single user mode 4. Ran "fixfiles relabel" 5. Rebooted with "selinux=1" Now, I'm seeing a lot of these: audit(1095681913.039:0(: avc: denied { search } for pid=2515 exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t tcontext=user_u:object_r"tmpfs_t tclass=dir The problem here is that I'm using UDEV and that the initial ramdisk mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" that resides on disk. How should I fix this?

5 5

More AVCs during boot
by Felipe Alfaro Solana 21 Sep '04

21 Sep '04

Hi! With selinux-policy-targeted, I get this during boot: audit(1095721178.335:0): avc: denied { associate } for pid=508 exe=/sbin/restorecon name=initctl dev=tmpfs ino=1992 scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem audit(1095721179.084:0): avc: denied { associate } for pid=721 exe=/usr/sbin/setfiles name=initctl dev=tmpfs ino=1992 scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem which seem related related to "/dev/initctl". audit(1095721179.097:0): avc: denied { associate } for pid=721 exe=/usr/sbin/setfiles name=.udev.tdb dev=tmpfs ino=366 scontext=system_u:object_r:udev_tbl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem which is related to /dev/.udev.tdb audit(1095714008.289:0): avc: denied { setrlimit } for pid=2218 exe=/usr/sbin/named scontext=user_u:system_r:named_t tcontext=user_u:system_r:named_t tclass=process related to bind audit(1095714008.771:0): avc: denied { read } for pid=2251 exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214 scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=file related to ntpd. Any ideas?

2 3

SELinux Symposium Call for Presentation Proposals
by Frank Mayer 21 Sep '04

21 Sep '04

CALL FOR PRESENTATION PROPOSALS FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) The inaugural symposium on Security Enhanced Linux (SELinux) will be held March 2-4 2005 in the Silver Spring, Maryland, USA (near Washington, DC). SELinux brings the power of flexible mandatory access control such as type enforcement to Linux. The symposium is an opportunity to learn about SELinux and share technical and application experiences. The call for presentation and tutorial proposals is now open until October 1, 2004. All proposals will be reviewed by the review committees for inclusion in the symposium agenda. To submit proposals visit http://www.selinux-symposium.org.

1 1

What is SELinux targeted policy?
by Daniel J Walsh 20 Sep '04

20 Sep '04

When FC2 was released we attempted to add the NSA strict policy to the operating system. We were able to find hundreds of problems in the policy and we quickly found out that users who customized their environments in unexpected ways caused SELinux and the OS to conflict. We decided at that point to take a step back and go with a strategy where we would lock down a few daemons with SELinux and allow the rest of the system to run in the same manner with or without SELinux. Targeted policy was born. In targeted policy most processes run in a unconfined_t domain, which means for the most part they are not being confined by the SELinux policy. They are still governed by Standard unix security, but not effected by SELinux. Certain network daemons have policy and the unconfined_t policy transitions to those policies when the application starts. So when the system boots init runs in the unconfined_t policy, but when named starts up it transitions to the named_t domain and is locked down. We use the following policies nscd.te apache.te dhcpd.te named.te ntpd.te portmap.te snmpd.te squid.te syslogd.te Also users can select which daemons he want to have SELinux to protect via system-config-securitylevel. So if an admin finds that SELinux will not allow his apache web server to run the way he wants he can turn off the transition. This will drop it back to normal Unix protections, but all other daemons will continue to be protected by SELinux. Through the use of these "boolean" values the admin can increase or decrease the level of protection SELinux provides. In the future we plan on adding additional Domains that SELinux will protect. Strict policy is still available but will be not be installable directly, you can use selinux-config-securitylevel to turn it on and relabel the file system. Dan

1 0

Variable naming confusion
by Bob Gustafson 20 Sep '04

20 Sep '04

To me, there is a lot of confusion in the naming and choice of values of the SELINUX booleans. (Maybe I just don't have my head around the concepts.. - but I don't think I am alone) For example: The variable 'SELINUX' in the file /etc/selinux/config has the value choices 'enforcing' or 'permissive'. The variable 'enforce' in the /boot/grub/grub.conf file has the value choices '=0' or '=1' The variable shown by the command 'getenforce' is either 'Permissive' or 'Enforcing' (note the initial capitalization) When using the runtime command 'setenforce', the argument is either '0' or '1' When using the script command 'selinuxenabled', the result is '0' if it IS enabled. Suggestions The variable 'SELINUX' is either 'enabled' or 'disabled' The variable 'enforcing' is either 'enabled' or 'disabled' (This can be named 'enforce' rather than 'enforcing' - would help when trying to remember whether the runtime command is 'setenforce' or 'setenforcing') The variable 'SELINUXTYPE' is 'strict', 'targeted', 'myownpolicy', 'strangleddaemons', etc.

3 3

Bug 129584: restrictions on user_t
by Ivan Gyurdiev 19 Sep '04

19 Sep '04

Bug link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129584 > Additional Comment #9 From Daniel Walsh (dwalsh(a)redhat.com) on > 2004-09-15 15:55 > Yes there are a lot of files that user can not access. Mainly any > file that has a security context associated with it and doesn't have > the attribute usercanread. > Again I want to bring this conversation to the public list and come to > concensus. We can add usercanread to these files, but the question > than is should a user be able to read all files even if they are world > readable. I don't see why not. If you think the user should not be able to read those files, then why aren't their permissions flags set accordingly? If a file was intended to be readable only by a certain application or only by root then it could have had the proper user/group/rwx flags set - this restriction could have been imposed without SELinux. If it is marked user readable then it seems to me that any user should be able to read it (or at least that there are no security reasons to deny it). So why does SElinux impose restrictions on user_t that contradict this explicit setting? -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

3 2

lsusb
by Tom London 19 Sep '04

19 Sep '04

Running strict/enforcing, latest Rawhide packages including latest from Dan's tree (selinux-policy-strict-1.17.18-2). Running 'lsusb' as root fails, but '/sbin/lsusb' as user works. [root@fedora ~]# lsusb cannot open /proc/bus/usb, Permission denied (13) Works in permissive mode. Here are the avc's from permissive mode: Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied { read } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied { getattr } for pid=13020 exe=/sbin/lsusb path=/proc/bus/usb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied { search } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied { read } for pid=13020 exe=/sbin/lsusb name=001 dev=usbfs ino=6351 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=file These look like: r_dir_file(sysadm_t, usbfs_t) r_dir_file($1_t, usbfs_t) is in user_macros.te. Should it be in base_user_macros.te? Included in admin_macros.te? tom -- Tom London

2 1

Re: please try SELinux again
by Colin Walters 18 Sep '04

18 Sep '04

On Sat, 2004-09-18 at 23:19 +0200, Lars wrote: > > when i try to enable selinux it only boots to the message > "setting up local disks" in rhgb and stays there. Hmm. Are you running the latest rawhide? Does it work again when you add enforcing=0 to the boot line? [We should move this discussion to fedora-selinux-list]

1 0

please try SELinux again
by Colin Walters 18 Sep '04

18 Sep '04

Hi, Talking with a number of people at the office, it seems a high percentage of Fedora developers disabled SELinux during FC2 test2, which was our first attempt at SELinux. Many other users and testers in the Fedora community likely did so as well. I think a lot of people are not aware that things have changed (and generally improved) dramatically since then. Instead of the original "strict" policy which covered everything, a new "targeted" policy has been developed which only applies SELinux restrictions to a few select system daemons. Regular user login sessions are unrestricted. This targeted policy will be enabled by default for FC3. But those of you who are upgrading from existing systems, if you earlier added selinux=0 to your grub config, or disabled it in /etc/sysconfig/selinux, will not be testing the new policy. Please: undo those changes, and give it another try. Be sure that /etc/sysconfig/selinux has these two lines: SELINUX=enforcing SELINUXTYPE=targeted Also be sure you don't have selinux=0 in your grub configuration.

1 0

Boolean utilities segv's
by George C. Wilson 17 Sep '04

17 Sep '04

Hi, We found what appears to be a bug in libselinux. The getsebool, setsebool, and togglesebool all SIGSEGV when SELINUX=disabled. The global that stores the selinuxfs mountpoint in libselinux, selinux_mnt, is initialized to NULL. selinuxfs is not mounted when SELinux is disabled, therefore no mountpoint exists when init_selinuxmnt() scans /proc/mounts, and selinux_mnt remains NULL. So when get_bool_value() in booleans.c attempts to strlen(selinux_mnt), a SIGSEGV results. The fix is to validate selinux_mnt before the offending strlen() in get_bool_value(), line 101 of booleans.c from selinux-usr-2004081908. It probably would not hurt to validate name as well. The same bug exists in FC3. Thanks -- George Wilson <ltcgcw(a)us.ibm.com> IBM Linux Technology Center

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux September 2004