selinux October 2004

selinux@lists.fedoraproject.org

48 participants
46 discussions

User file access auditing
by Barry Roomberg 22 Oct '04

22 Oct '04

I have setup a Fedora 2 box with SELinux enabled. I'm able to add users and relabel /home to allow their .ssh keys to work, so I have a baseline install that is working. I would like to create a shared dir tree that certain users have full access to. Every file access that reads or writes data (stat, open, read, write, delete, rename, ???) should be logged, while still allowing the operation to complete. Is SELinux appropriate for that type of tracking? If so, can anyone give me a hint on the way to construct the policy? Thanks. Barry

2 2

(no subject)
by Manel Garcia 19 Oct '04

19 Oct '04

1 0

SELinux and the Desktop
by Jerry Haltom 18 Oct '04

18 Oct '04

Howdy. I really have nothing at all to do with Fedora, don't use it. Never even seen it. However, you seem to be the only group interested in SELinux for the masses, so I'm going to lay out an idea I've had. SELinux has a place on the desktop. Currently, a large piece is missing from the desktop security landscape. User's can receive, by email or IM, executable files. These can be in the form of actual real binaries, pseudo-binaries (flash), or script languages (javascript, html, etc). Up to now the current attitude has been "don't open files you don't trust, don't go to websites you don't trust, don't run scripts you don't trust". This "rule" ignores one common principle. USERS DONT CARE! It doesn't matter that they SHOULDN"T open an executable their friend or co-worker sends them, they will anyways. Is this so bad? I don't think so. So here's where SELinux comes in. SELinux allows the system to place restrictions on executable programs beyond that offered by the user identity itself. It allows you to audit, and deny syscall execution, which is every programs interface to the world. So why can't one program place SELinux policy's on other software? Why can't a desktop interface listen for faults in SELinux, change those policy's based on the user's actions or requests, and let the program continue, at runtime? Consider the following example: Bob receives an executable from his co-worker Joe. Bob opens it from his email. His email client sets up a policy restricting all access to everything, except maybe /tmp, and the obvious, the program runs. Oh no! It's a virus! The program attempts to establish a connection to Bob's address book (exposed by evolution data server). SELinux detects the programs attempts to open a socket that it was not allowed to do. The program blocks on the syscall. SELinux is configured to continue blocking the program until told otherwise. SELinux locates a D-BUS daemon for Bob and notifies it about the security event. Running as Bob is sec-policy-daemon which is listening to D-BUS for fault notifications. This daemon reads the information Bob's email client attached to the process. The information reads as follows: 1) don't allow the program to do anything except read/write to /tmp 2) do allow the program to open outgoing ports after notifying the user The daemon realizes that the action isn't allowed, but that it could be allowed if the user consents to it, so the daemon pops up on the user's desktop a nice dialog box, "The application Blah has attempted to access the file /tmp/contact-socket (or whatever). Do you want to allow this action?" Most likely t his dialog would ask for the user's password again. Upon receiving a "Yes", SELinux would be instructed to allow the program to access the socket. If the user presses Yes, the process ceases being blocked, and goes on. In the case of No, the process will probably die. ;0 Of course this policy would be configurable. In some offices admins would probably not want the user to even have the option to open outgoing ports from downloaded software, they just don't wnat to take the risk. In some home circumstances, it might be a little bit looser. It's up to you. What this does is let users do what they will do anyways: run the program. You won't stop them, I won't stop them, and we probably shouldn't. We should make it so they CAN without risk to their systems. Do enjoy. I hope you guys do something with this. It's what we need. Jerry Haltom wasabi(a)larvalstage.net

8 16

SELinux Testing Software/Scripts
by Alex Ackerman 17 Oct '04

17 Oct '04

This may sound like an odd request, but I am currently working on my master's thesis on the topic of SELinux integration into the workplace. Part of the analysis involves testing the security containment capabilities of SELinux; i.e., making sure that SELinux functions as advertised when dealing with events of escalating privilege. Does anyone on this list have any recommendations on scripts or programs which can test these capabilities? My test platforms are Fedora Core 3 (once released) and Red Hat Enterprise Linux v4.0 Beta 1. My current thinking would be to downgrade certain packages (httpd, etc) to a known vulnerable state and test, but would like to know how the members on the list test their systems. Any help would be appreciated. I can be reached at ackermal at jmu dot edu or alex at darkhonor dot com if you would like to discuss this off-list. Thank you for any assistance. Alex Ackerman James Madison University

5 5

writing rules to disallow a domain to read particular files
by Jaspreet Singh 16 Oct '04

16 Oct '04

Hi, can someone help me with writing policy rules such that - A domain (say apache_d) cannot access files beyond a directory /home/jaspreet/ any clues ??? Jaspreet

1 0

udev strangeness with latest rawhide
by Russell Coker 16 Oct '04

16 Oct '04

Running the latest rawhide I get AVC messages indicating that /bin/udev (not /sbin/udev) is running in kernel_t during the early stages of system boot. /bin/udev is the file name used in the initrd! So it seems that after the SE Linux policy is loaded (IE after /sbin/init has been run from the main root fs) there is still a copy of udev from the initrd being run. This seems to be a bug in initrd that could lead to inconsistent behaviour. I'm not sure how this comes about (and of course apart from SE Linux messages in the kernel message log all the evidence is gone by the time the system is ready to login). Any suggestions on how to debug this? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page

1 0

Kernel Panic on upgrading libselinux
by Jaspreet Singh 15 Oct '04

15 Oct '04

Hi, I wanted to write my own security policies so i upgraded to packages given shipped with FC3 ( libselinux , policy-targeted, policycoreutils , SysVinit and checkpolicy) When i tried to reboot (to 2.6.5-1.358 default with FC2) with SELINUX=enforcing and SELINUXTYPE=targeted .. it says - kernel panic ... No policy loaded ????????? i tried booting to kernel 2.6.8-1.386 .. it booted fine ... Then i also tried to run "fixfiles relabel" and rebooted same problem. also booting with SELINUX=permissive gives the following errors on "ls -Z" Option only possible with selinux enabled kernels ??????? Any clues ??? Jaspreet :-(

2 1

prelink and yum conflict
by Tom London 15 Oct '04

15 Oct '04

If prelink is running from cron when you do a 'yum install' of a package that want's to do a ldconfig, you get the following avc Oct 8 08:31:39 fedora kernel: audit(1097249499.123:0): avc: denied { read } for pid=14475 exe=/lib/ld-2.3.3.so name=ld.so.cache dev=hda2 ino=4473477 scontext=system_u:system_r:prelink_t tcontext=root:object_r:etc_t tclass=file and a message from ldconfig complaining about not being able to link ld.so.cache~ I believe (hope?!) that this is harmless. But, does it make sense to prevent this, say by creating a lock files that would be used to prevent prelink and ldconfig from colliding? Or is it safe to allow this access? A 'dontaudit' would still leave curious looking messages during the yum. tom -- Tom London

7 20

Try my experimental rsync with xattr support
by Jay Fenlason 14 Oct '04

14 Oct '04

I've written a patch to rsync that adds support for transferring posix extended attributes. I've put the srpm and an i386 binary rpm at http://people.redhat.com/fenlason/rsync/rsync-2.6.3-2.{src,i386}.rpm These rpms also contain the acl patch. To enable the transfer of extended attributes you need to use the new -X option. Naturally, both the client and server rsyncs must include the extended attribute patch if you use -X. Please try this rpm out, and report whether it works or not. After I get some feedback I'll be sending the patch (or its successor) to the upstream rsync maintainer. -- JF

6 7

User policy problem with strict policy
by James Morris 14 Oct '04

14 Oct '04

I'm using the latest fedora strict policy sources, and have noticed that the generated policy.conf file is lacking generated policy entries for extra users. I added myself to the users file: # sample for regular user user jmorris roles { user_r }; compiled policy: # make policy.conf But the only entry related to the user is the one I added in the users file: # grep jmorris policy.conf user jmorris roles { user_r }; Have I missed a step or is something wrong in the policy compilation process? - James -- James Morris <jmorris(a)redhat.com>

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux October 2004