selinux April 2006

selinux@lists.fedoraproject.org

69 participants
97 discussions

RE: problems with tmpfs and relabeling
by Joshua Brindle 21 Apr '06

21 Apr '06

> From: Bill Nottingham [mailto:notting@redhat.com] > > Joshua Brindle (jbrindle(a)tresys.com) said: > > > Yes, but that tends to imply some fairly severe gun -> foot > > > interactions on the part of the admin. > > > > The admin need not know what is going on, how many things happen on > > average linux systems without an average admins knowledge? > > Well, I'd hope that remounting the root FS read-write > wouldn't be one of those. Arguably, you could even set up the > policy to disallow this. > > > I retract the above statement. Even when making > non-persistent boolean > > changes (which I can see happening on these systems) the lock is > > attempted. Its still unclear whether setsebool should > fallback or if > > libsemanage should. I don't like the idea of lockless > readers, even if > > the filesystem is RO when we start reading. > > Hm, I didn't consider booleans. How (at an implementation > level) is setting of booleans done? (I've haven't looked at > the backend guts of the SELinux code that much.) > In the non-persistent case it checks whether the store is managed and then does the libselinux calls to set the boolean so that actually won't be a problem. Also, Karl claims that lockf works on a RO filesystem so the actual problem is that we always open the lock file with O_RDRW | O_CREAT but we can change it to try a read only open first and if it isn't there try to create it and then bail after that. If the store has been properly initialized the lock files will be present, the O_RDONLY open will succeed and the lockf call will succeed and the query should work fine. This is a pretty trivial change, do you think it will work Steve?

1 0

RE: problems with tmpfs and relabeling
by Joshua Brindle 21 Apr '06

21 Apr '06

> From: Bill Nottingham [mailto:notting@redhat.com] > > Joshua Brindle (jbrindle(a)tresys.com) said: > > > Likely, but we'd want to distinguish the ro mount case from a rw > > > mount where the read lock acquisition fails for some > other cause. > > > Likely can just test for errno EROFS when > > > semanage_get_active_lock() fails, and proceed with rdonly > operations > > > in that case? cc'd Tresys folks above. > > > > Not sure about this, if the mount becomes rw in the middle > of a EROFS > > read the policy can changed underneath them. > > Yes, but that tends to imply some fairly severe gun -> foot > interactions on the part of the admin. > The admin need not know what is going on, how many things happen on average linux systems without an average admins knowledge? > > I guess I'm unsure where > > this sudden push for ro filesystem support is coming from > and why its > > important. Any kind of read only / system is going to have a highly > > abstracted interface. I have serious doubts that there would be any > > users running a bash shell and trying to get a list of modules. > > http://fedoraproject.org/wiki/StatelessLinux > I retract the above statement. Even when making non-persistent boolean changes (which I can see happening on these systems) the lock is attempted. Its still unclear whether setsebool should fallback or if libsemanage should. I don't like the idea of lockless readers, even if the filesystem is RO when we start reading. I'm open to suggestions, the easiest thing to do in this case is propagate the EROFS error back up to setsebool to fall back but that doesn't address the other semodule/semanage operations, but I'm dubious as to whether those are useful at all on a setup like this.

2 1

RE: problems with tmpfs and relabeling
by Joshua Brindle 21 Apr '06

21 Apr '06

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] > > On Fri, 2006-04-21 at 12:54 -0400, Bill Nottingham wrote: > > Stephen Smalley (sds(a)tycho.nsa.gov) said: > > > we need a rw mount on /etc/selinux separate from the rest > of root so > > > that we can perform policy module operations. > > > > I'm not as sure about this now that I understand how semodule is > > supposed to work. If you're running a read-only system, you > shouldn't > > need to add or remove modules at runtime - that's something you do > > when preparing the image to run read-only. That only leaves listing > > modules, which I presume can be fixed to not need write access? > > Likely, but we'd want to distinguish the ro mount case from a > rw mount where the read lock acquisition fails for some other > cause. Likely can just test for errno EROFS when > semanage_get_active_lock() fails, and proceed with rdonly > operations in that case? cc'd Tresys folks above. Not sure about this, if the mount becomes rw in the middle of a EROFS read the policy can changed underneath them. I guess I'm unsure where this sudden push for ro filesystem support is coming from and why its important. Any kind of read only / system is going to have a highly abstracted interface. I have serious doubts that there would be any users running a bash shell and trying to get a list of modules.

2 1

Does MAP_FIXED inhibit execmem denial?
by John Reiser 21 Apr '06

21 Apr '06

I develop the Linux+ELF side of UPX, which compresses executable programs to save storage space and invocation time. Immediately after kernel execve() of a compressed program, a small decompressor reconstructs the original PT_LOADs directly into address space; then execution proceeds as usual. The decompression writes instructions which execute later, directly into pages with both PROT_WRITE and PROT_EXEC, so perhaps there should be a { denied } avc due to execmem when SELinux is in enforcing mode. Reading the explanation of execmem in http://people.redhat.com/drepper/selinux-mem.html supports this theory. However, under all released FC5 kernels including 2.6.16-1.2096_FC5, I see no execmem complaints. Strace of typical execution begins: ----- old_mmap(0xc06000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0xc06000) = 0xc06000 /* interval [0xc06000, +4096) is written and executed >now< */ old_mmap(0x8048000, 45056, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8048000 old_mmap(0x8048000, 40647, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x8048000 /* interval [0x8048000, +40644) is written >now< */ mprotect(0x8048000, 40644, PROT_READ|PROT_EXEC) = 0 /* interval [0x8048000, +40644) is executed later */ old_mmap(0x8052000, 3800, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0xa000) = 0x8052000 ----- Notice that the first and third old_mmap() specify (PROT_WRITE | PROT_EXEC) with (MAP_FIXED | MAP_ANONYMOUS) [and other bits, too.] SELinux was is targeted enforcing mode, and this was an unconfined compressed executable. How did these system calls evade being denied due to execmem? --

2 3

Question about log entries
by Knute Johnson 20 Apr '06

20 Apr '06

I really don't have a good grasp on how selinux works so simple explanations will be better. This showed up in my log this morning. What would generate this sort of an entry? Thanks, knute... --------------------- Selinux Audit Begin ------------------------ *** Denials *** user_u system_u (file): 48 times user_u user_u (process): 1 times ---------------------- Selinux Audit End ------------------------- -- Knute Johnson Molon Labe...

2 1

httpd and newly mounted file systems
by Michael Chester 20 Apr '06

20 Apr '06

Hi all, I've recently added a new filesystem on a new disk to our system and would like to RTM to understand how to get httpd to be able to access it. I have been unable to locate suitable documentation on how to do this. Currently I just get a message telling me that httpd is unable to list '/'. If someone could point me at a piece of doco or an earlier thread on the topic of how to do this I would really appreciate it. Thanks in advance. Regards, Michael C This electronic message together with any attachments is confidential, and may be privileged. It is intended solely for the addressee. If you are not the intended recipient do not copy, disclose, or use the contents in any way and please notify us by return e-mail immediately, then destroy the message. ETSL is not responsible for any changes made to this message and/or any attachments after sending by ETSL.

2 1

Create new types in modules?
by Paul Howarth 20 Apr '06

20 Apr '06

Is it possible to create new context types in a loadable module? Here's why I ask: I'm trying to use mock to build packages on FC5 targeted at older distributions, like Red Hat 8 for instance (more on mock at http://fedoraproject.org/wiki/Legacy/Mock and http://fedoraproject.org/wiki/Projects/Mock) What mock basically does is to create a chroot with a build environment for the target distribution and runs a regular rpm build within that chroot, pulling in the other distro's binaries, shared libraries, etc. Mock's approach to SELinux is simple: it loads a dummy libselinux that effectively turns it off. However, with FC5, this no longer seems to be enough. The memory tests don't like loading ancient DSO's that don't have separate stack segments and so some builds fail with execmod errors. I tried using semanage to set the default context for .so.* files under the chroot to textrel_shlib_t but although restorecon targeted those files properly, the contexts weren't set properly within the chrooted build (would I have to remove the chroot prefix in the semanage call to get that to work? it's not something I want to do as I'll get the wrong contexts on files in the host system that way). So, my idea was to define everything under my chroot as a new type, mock_root_t, and then have a module like this: module mock 0.2; require { class file execmod; type unconfined_t; type mock_root_t; }; allow unconfined_t mock_root_t:file execmod; However, I can't load this module using semodule because mock_root_t doesn't exist. So is there a way of defining a new type in a module? Paul.

3 8

FC5 CUPS and Netatalk (fixed?)
by Tony Nelson 19 Apr '06

19 Apr '06

I've just fixed an SELinux policy issue on FC5, printing via CUPS to a printer connected via Netatalk (AppleTalk). I upgrade installed from FC3 to FC5. I had Netatalk 1.6.x on FC3, with SELinux enforcing, and could print via CUPS over Ethernet to a printer on a Mac on Localtalk. After the upgrade (and getting Netatalk working again) it would only print with SELinux in permissive mode. After a few tries, I collected the following AVC messages and used audit2allow to make the module below, installed it, and printing works again. I don't know if this module is exactly right, or even if it is generally needed by CUPS or only for PAP with Netatalk. type=AVC msg=audit(1145484476.381:82): avc: denied { create } for pid=8035 comm="pap" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tclass=socket type=AVC msg=audit(1145485638.551:86): avc: denied { bind } for pid=8215 comm="pap" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tclass=socket type=AVC msg=audit(1145485978.490:91): avc: denied { getattr } for pid=8291 comm="pap" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tclass=socket type=AVC msg=audit(1145486131.769:96): avc: denied { write } for pid=8336 comm="pap" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tclass=socket type=AVC msg=audit(1145486380.729:103): avc: denied { read } for pid=8408 comm="pap" scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tcontext=system_u:system_r:cupsd_t:s0-s0:c0.c255 tclass=socket ------- pap.te ------- module pap 1.0; require { class socket { bind create getattr read write }; type cupsd_t; }; allow cupsd_t self:socket { bind create getattr read write }; ------- ____________________________________________________________________ TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>

1 0

SElinux Removal?
by idonttrustmspassport＠ktcasey.plus.com 19 Apr '06

19 Apr '06

Is it possible to remove SELinux completely during FC5 installation, or even when installed? So far problems during YUM updates (It gives errors while installing policies then freezes Yum) have destroyed my system twice. (In both cases the system refuses to boot with an error "not syncing: Attempting to kill init!". Passing a parm of selinux=disabled to the kernel allowed a boot, but all my attempts to make this permanent then fail and I end up reinstalling and reconfiguring. I *cannot* complain that it is insecure, I can't even edit the files to disable it more permanently from the rescue function.. My problem is that for the systems I build it is overkill at the "BFG to kill a flea level"... I admit to being a newbie, I only started 10 years ago, *never* had anything so good at locking down my PC, it seems to be a first class option for DRM.. So, can I get rid of it completely, 1) I tried uninstalling everything with SELinux in the name, interesting effect try it one day when you have some time... 2) Tried the gui tool, (as a minimum I thought I'd turn it to the lowest level) it brings up a command prompt which freezes... 3) Tried editing the files to disable it at reboot, fails with "file is read only", chmod failed with "file is read only", chmod of the directory failed with "read only".. Is there any chance that, as a minimum it could give an error message like "SELinux configuration is corrupt, boot halted" as it took me a loooooong time to figure out what was wrong... And is there a documented process to handle a situation where the configuration is corrupted (accidentally or during an update) and the whole system is locked? Don't (Please don't) take this in the wrong way, I quite like FC5 apart from the effects of the new security, and I am sure there are people that need this, it's just for me the cure is proving much worse than the disease. Keiron Casey

5 6

hald / <<none>> / semanage
by Mike Carney 19 Apr '06

19 Apr '06

I posted the following a few days ago. Some more information: It seems that all hald wants to do is view the root directory of the mounted filesystem. After downloading, installing, and viewing the policy source files, it seems rather excessive to grant hald permission to search all directories on the mounted volume. Is the fix to change the policy to simply not to audit the attempts of the hald domain to get attributes of all filesystems? Or add a rule to always relabel the root directory of any r/w filesystem to some standard context the hald domain is granted access to? Finally, there doesn't appear to be a way to convince semanage to accept the '<<none>>' (don't recurse when relabeling) keyword when adding a context. Is this a bug? Guidance as to what the right thing to do would be appreciated (I don't mind submitting a bug, just as long as I have the right information to place in it). TIA. > Re: FC5: what context should I use for extra ext3 filesystems? > Daniel J Walsh wrote: > > > > Ok lets fix hal then. What is it complaining about? > > 45# audit2why < /tmp/y > type=AVC msg=audit(1145036599.405:1110): avc: denied { search } for > pid=2452 comm="hald" name="export" dev=sdb2 ino=8161 > scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:object_r:default_t:s0 tclass=dir > Was caused by: > Missing or disabled TE allow rule. > Allow rules may exist but be disabled by boolean settings; > check boolean settings. > You can see the necessary allow rules by running audit2allow > with this audit message as input. > > <and so on...> > > Looks like we need: > > 47# audit2allow < /tmp/y > allow hald_t default_t:dir search; > 48# > > BTW, how does one use semanage to specify that a context not recurse > to subdirectories? (e.g. <<none>>).

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux April 2006