RE: problems with tmpfs and relabeling
by Joshua Brindle
> 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?
18 years
RE: problems with tmpfs and relabeling
by Joshua Brindle
> 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.
18 years
RE: problems with tmpfs and relabeling
by Joshua Brindle
> 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.
18 years
Does MAP_FIXED inhibit execmem denial?
by John Reiser
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?
--
18 years
Question about log entries
by Knute Johnson
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...
18 years
httpd and newly mounted file systems
by Michael Chester
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.
18 years
Create new types in modules?
by Paul Howarth
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.
18 years
FC5 CUPS and Netatalk (fixed?)
by Tony Nelson
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/>
18 years
SElinux Removal?
by idonttrustmspassport＠ktcasey.plus.com
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
18 years
hald / <<none>> / semanage
by Mike Carney
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>>).
18 years
