So I'm still stumbling along in the dark trying to get livecd-creator to
build me a nice new F10 image inside an F10 host. I've actually got an
image that built and runs, but not without its issues.
my kickstart file has:
auth --enableshadow --enablemd5
but the livecd always has x for the password in /etc/password and * for
the password in /etc/shadow. No ideas here I must admit. I'm highly
doubtful its selinux since it happens in permissive and enforcing. I
have just been booting into single user, calling passwd, init 3, and
logging in to play around in my live image....
3 errors/issues/quirks in building/running my livecd
1) libsemanage.dbase_llist_query: could not query record value
I'm told empty table, but I don't know what that means
2) /usr/sbin/semanage: Invalid prefix user
This pops out when semanage calls:
if selinux.security_check_context("system_u:object_r:%s_home_t:s0" % prefix) != 0:
I assume this has to do with my bastardized /selinux inside the chroot.
Should we just make it != 0 && != -ENOENT or whatever the error is we
3) When booting I get 3 messages that say:
inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345
The 3 inodes in question correspond to
no clues where this is coming from. I don't see it when I booted my
Anyway, at this point I want clues/help/suggestions on how to create my
hacked up /selinux inside the chroot. Right now all I'm going is
creating it on the host system and bind mounting it into the chroot. I
really should be creating this inside creator.py. All that needs to be
inside it is 3 files. copies of mls and policyvers from the host
system and load is a chrfile of /dev/null. I could just create those in
the livecd image and they will get mounted on top of when its running,
but I don't want to waste the 50 bytes or whatever it would take. Any
good suggests on how to build this temp? Or where I could clean it out
I've spent pretty much all week flailing around try to get
livecd-creator working with selinux enforcing with F10 as both the host
and the image. Next week begins the journey of working on making old
composes work on F10. Where do I stand? Well, it seems to work! I
booted an image and logged in.
Changes I've made so far (doesn't look like a whole lot for basically a
week of work....)
policycoreutils got some updates to allow users to be created in the
chroot (already built and in koji) and to make relabeling a little
libselinux has no changes with my current approach. I do not want rpm
running inside the chroot to transition to rpm_t, nor do I want
scriptlets to run as rpm_script_t as then those scriptlets can cause
transitions to things like depmod_t which isn't going to have
permissions necessary to run with the possibly screwy labels inside the
I added one rule to policy to allow hal to respond back to chroot
allow hald_t unconfined_notrans_t:dbus send_msg;
Create a fake /selinux inside the chroot it contains:
mls -> copy from host
poliyver -> copy from host
enforce -> 0
load -> /dev/null
This means that from the point of view of the inside of the chroot
selinux is "on" but not enforcing. The not enforcing part is important
because some programs (passwd for example) try to determine if selinux
is going to permit something before it actually tries it. If passwd
realizes that selinux is enforcing but then it doesn't have a
real /selinux to make those decisions it gets mad. So I'm lieing to the
Changes to livecd-creator:
diff -Naupr imgcreate/creator.py imgcreate.new/creator.py
--- imgcreate/creator.py 2008-05-06 12:16:08.000000000 -0400
+++ imgcreate.new/creator.py 2008-05-16 13:01:05.000000000 -0400
@@ -22,6 +22,7 @@ import stat
@@ -427,7 +428,7 @@ class ImageCreator(object):
- for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum"):
+ for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum", "/sys", "/proc"):
makedirs(self._instroot + d)
cachesrc = cachedir or (self.__builddir + "/yum-cache")
@@ -439,10 +440,6 @@ class ImageCreator(object):
self.__bindmounts.append(BindChrootMount(f, self._instroot, dest))
- # /selinux should only be mounted if selinux is enabled (enforcing or permissive)
- if kickstart.selinux_enabled(self.ks):
- self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None))
# Create minimum /dev
origumask = os.umask(0000)
devices = [('null', 1, 3, 0666),
@@ -460,6 +457,20 @@ class ImageCreator(object):
os.symlink('/proc/self/fd/2', self._instroot + "/dev/stderr")
+ # selinux whoo hooo
+ if kickstart.selinux_enabled(self.ks):
+ makedirs(self._instroot + "/selinux")
+ # this should actually create our new fake /selinux, not bind from the host, though i haven't decided how
+ self.__bindmounts.append(BindChrootMount("/selinux1", self._instroot, "/selinux"))
+ # label the fs like it is a root before the bind mounting
+ cmd = "/sbin/setfiles -F -r %s %s %s" % (self._instroot, selinux.selinux_file_context_path(), self._instroot)
+ # these dumb things don't get magically fixed, so make the user generic
+ for f in ["/proc", "/sys", "/selinux"]:
+ cmd = "chcon -u system_u %s" % (self._instroot + f)
os.symlink("../proc/mounts", self._instroot + "/etc/mtab")
diff -Naupr imgcreate/kickstart.py imgcreate.new/kickstart.py
--- imgcreate/kickstart.py 2008-05-06 12:16:08.000000000 -0400
+++ imgcreate.new/kickstart.py 2008-05-15 10:10:40.000000000 -0400
@@ -372,11 +372,11 @@ class SelinuxConfig(KickstartConfig):
if ksselinux.selinux == ksconstants.SELINUX_DISABLED:
- if not os.path.exists(self.path("/sbin/restorecon")):
+ if os.path.exists(self.path("/sbin/restorecon")):
+ self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"])
- self.call(["/sbin/restorecon", "-l", "-v", "-r", "/"])
def apply(self, ksselinux):
args = ["/usr/sbin/lokkit", "-f", "--quiet", "--nostart"]
On Mon, 2008-05-19 at 09:11 -0400, David Huff wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Eric Paris wrote:
> | I've spent pretty much all week flailing around try to get
> | livecd-creator working with selinux enforcing with F10 as both the host
> | and the image. Next week begins the journey of working on making old
> | composes work on F10. Where do I stand? Well, it seems to work! I
> | booted an image and logged in.
> I have seen similar issues with the appliance-tools Im working on
> (thincrust.net). On thing I have noticed is that kickstart.py only
> likes crypted passwds, so make sure you use the --iscrytped option in
> the ks file.
> I have also noticed another problem, if you set selinux disabled via the
> kickstart and try to set no root passwd, by excluding a rootpw
> line in the ks, you get an error similar too:
> "only root can do that"
> I think this is due to selinux context on the host you are
> building the image on. I saw this running a F9 client on a F9 host,
> from your post on Friday, I will try generating a rwahide image on a
> rawhide host and see if I have similar results.
If you wouldn't mind opening a BZ, for now lets open it against
libselinux assign it to me and let me know all of the problems you have
run into involving passwd. I think I understand all of that cruft now.
There are some differences in how openssh and pam_selinux get the user's
context. As I want to replace part of the openssh's SELinux code with
pam_selinux I'd like to know which one is more correct.
Here's the rough algorithm for both:
1. get selinux user & default level with getseuserbyname()
2. obtain default ctx with get_default_context_with_level()
3. obtain requested ctx for requested level with
4. set requested role to the requested ctx
5. set type for the requested role to the requested ctx (obtained from
6. copy the requested ctx and set the requested level in the copy
7. compare the requested ctx with the copy - if not equal -> fail
8. do the points 3. - 7. with the difference that the default level is
used instead of requested level
9. do security_compute_av with CONTEXT__CONTAINS to check whether the
context from 7. is allowed for context from 8. if not allowed -> fail
10. use the context from 7. as the user's context.
1. get selinux user & default level with getseuserbyname()
2. use get_ordered_context_list_with_level() to obtain list of context
for the user & level, as the default user's context is taken the first
one on the list
3. if this fails:
3a. the level and role is obtained from user and combined into a
context with default type for the role and the selinux user
3b. this ctx is checked with security_check_context() - if fails ->
fail else we have the user's context -> end
4. if 2. succeeds and module is configured to allow asking user for
role/level then user is asked for requested role and level
5. the requested ctx starts as copy of the default ctx
6. the requested role is set to requested ctx, requested level is set
and the default type (get_default_type()) for the requested role is set
7. the requested ctx is checked with security_check_context() - if fails
8. do security_compute_av with CONTEXT__CONTAINS to check whether the
context from 7. is allowed for default context if not allowed -> fail
9. use the context from 7. as the user's context.
So which one is correct if any?
No matter how far down the wrong road you've gone, turn back.
SELinux appears to stop spamc from being called from procmail:
type=1401 audit(1210924808.115:14): security_compute_sid: invalid
context system_u:system_r:spamc_t:s0 for
/usr/bin/spamc: /usr/bin/spamc: cannot execute binary file
procmail: Error while writing to "/usr/bin/spamc"
procmail: Rescue of unfiltered data succeeded
In my .procmailrc I have this line:
Used to work fine in previous releases of Fedora.
Is there anything I could set to allow this?
I have already tried a full touch ./autorelabel && reboot, it didn't
SELinux is using
I'm a student of the university of Rostock, In the scope of my master
thesis I want to get an
overview about existing graphical tools (commercial or free),
abstracting from underlying SELinux
details, helping users to define and maintain SELinux policies (TE &
MCS). So far, I found the
- Tresys Brickwall Security Suite
They only use masks for data input and don't abstract from the policy
to show a graph.
My questions are:
- Is there any tool that creates a abstract view of a policy as a
graph or something like that?
- Is there any demand for such a tool?
Thanks in advance
As announced on fedora-devel-list, we'd like to come to a resolution
(consensus, actions) on the challenges we have with SELinux in the
Fedora build system.
I expect the following:
* All the parties are here now needed to figure this out
* Someone better than me is going to reply with specifics about what is
not working in the buildsys
* We all agree it's pretty important to get this figured out in a good
One example of a project blocking on this work is the Fedora spin
server. We would have to put a non-SELinux secured server in the loop
somewhere for the actual spin building, and any way we do that is going
to be hacky and whacky.
The main problem I see outside of the technical issues is a marketing
one. Fedora's infrastructure is a set of open tools that anyone can
download and make work themselves. We know that people do that. Fedora
Infrastructure is a feature producer; just as Fedora Docs supplies a
full-course documentation toolchain, so does Infrastructure supply a
full-course FLOSS project toolset.
We do *not* want to be explaining that a new feature doesn't work with
SELinux. At the very minimum, we have been consistent about the value
of SELinux in Fedora, and to ship something as a Fedora feature that
cannot run under SELinux ... well, that would be bad.
This is why other Fedora folks are asking the Fedora SELinux team to
take this off the backburner.
Thanks - Karsten
 Yep, that's right; Fedora Infrastructure is a feature of Fedora.
For example, the new grid project 'Fedora Sleepwalker' is looking to get
integrated into firstboot or some kind of JoinBuddy. When that happens,
adding your install to the Fedora Sleepwalker grid is going to be touted
as a major feature for that release.
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
I'm having a problem setting up polyinstantiation for the /tmp dir. I'm
using RHEL5.1 and I've set it up to create instance directories under
the /tmp-inst directory based on level when using newrole. It works, but
the instance directory has ownership/permissions (dac permissions) set
so that the user can not write to the polyinstantiated directory
#ls -l /tmp-inst/
drwxr-xr-x 2 root root 4096 May 14 20:17
drwxr-xr-x 2 root root 4096 May 14 18:40
Either the directories need to be created with the user as the owner
(clarkson in this case), or the permissions need to be 777.
I've set this up before on other boxes and had it work. Not sure what
the difference is now. Any ideas?
Daniel J Walsh wrote:
|Daniel B. Thurman wrote:
|| Stephen Smalley
|| |Daniel B. Thurman wrote:
|| |> |You can certainly generate a local policy module that gives
|| |> |access to fusefs_t, but it would be better if we could get
|| |> |the context mount option to work.
|| |> I will try anything you suggest. Let me know if you can
|| |> resolve this issue, otherwise let me know (in detail) how
|| |> to write a policy as a last resort?
|| |To generate local policy for this issue, you'd do something
|| |$ su -
|| |# ausearch -m AVC | grep fuse | audit2allow -M myfuse
|| |# semodule -i myfuse.pp
|| |Then the fuse-related denials should be allowed.
|| Uh, almost. It still will not allow me to chmod or chgrp
|| the mounted filesystem which means that I cannot write to
|| the shared NTFS filesystem without assigning the proper
|| permissions. I have set samba properties to allow writes
|| but apparently this problem resides with fuse again. Grr.
|| What can I do to allow samba shared writes?
|Look for additional AVC's with ausearch
|You can run the above command another time.
|You can put the machine into permissive mode and gather all of the AVC
|Run your test
|ausearch -m AVC | grep fuse | audit2allow -M myfuse
|semodule -i myfuse.pp
Yup! That worked!