* Re: rawhide targeted vs. refpolicy rpm
[not found] ` <1131983537.5415.137.camel@moss-spartans.epoch.ncsc.mil>
@ 2005-11-14 16:17 ` Daniel J Walsh
2005-11-14 16:51 ` Stephen Smalley
` (2 more replies)
2005-11-14 18:09 ` I have modified Joshua's libsemanage-swigify patch to work better in my spec file Daniel J Walsh
1 sibling, 3 replies; 30+ messages in thread
From: Daniel J Walsh @ 2005-11-14 16:17 UTC (permalink / raw)
To: Stephen Smalley, SE Linux
[-- Attachment #1: Type: text/plain, Size: 90 bytes --]
policycoreutils patch to genhomedircon to use libsemanage to read
seusers file.
--
[-- Attachment #2: policycoreutils-rhat.patch --]
[-- Type: text/x-patch, Size: 13828 bytes --]
diff --exclude-from=exclude -N -u -r nsapolicycoreutils/scripts/genhomedircon policycoreutils-1.27.27/scripts/genhomedircon
--- nsapolicycoreutils/scripts/genhomedircon 2005-09-12 16:33:30.000000000 -0400
+++ policycoreutils-1.27.27/scripts/genhomedircon 2005-11-11 15:43:58.000000000 -0500
@@ -15,32 +15,19 @@
# The file CONTEXTDIR/files/homedir_template exists. This file is used to
# set up the home directory context for each real user.
#
-# If a user has more than one role in CONTEXTDIR/local.users, genhomedircon uses
-# the first role in the list.
+# If a user has more than one role, genhomedircon uses the first role in the list.
#
-# If a user is not listed in CONTEXTDIR/local.users, he will default to user_u, role user
+# If a user is not listed in CONTEXTDIR/seusers, he will default to user_u, role user
#
# "Real" users (as opposed to system users) are those whose UID is greater than
# or equal STARTING_UID (usually 500) and whose login is not a member of
-# EXCLUDE_LOGINS. Users who are explicitly defined in CONTEXTDIR/local.users
+# EXCLUDE_LOGINS. Users who are explicitly defined in CONTEXTDIR/seusers
# are always "real" (including root, in the default configuration).
#
#
-# Old ASSUMPTIONS:
-#
-# If a user has more than one role in FILECONTEXTDIR/users, genhomedircon uses
-# the first role in the list.
-#
-# If a user is not listed in FILECONTEXTDIR/users, genhomedircon assumes that
-# the user's home dir will be found in one of the HOME_ROOTs.
-#
-# "Real" users (as opposed to system users) are those whose UID is greater than
-# or equal STARTING_UID (usually 500) and whose login is not a member of
-# EXCLUDE_LOGINS. Users who are explicitly defined in FILECONTEXTDIR/users
-# are always "real" (including root, in the default configuration).
-#
import commands, sys, os, pwd, string, getopt, re
+from semanage import *;
EXCLUDE_LOGINS=["/sbin/nologin", "/bin/false"]
@@ -67,169 +54,6 @@
starting_uid = 500
return starting_uid
-#############################################################################
-#
-# This section is just for backwards compatability
-#
-#############################################################################
-def getPrefixes():
- ulist = pwd.getpwall()
- STARTING_UID=getStartingUID()
- prefixes = {}
- for u in ulist:
- if u[2] >= STARTING_UID and \
- not u[6] in EXCLUDE_LOGINS and \
- u[5] != "/" and \
- string.count(u[5], "/") > 1:
- prefix = u[5][:string.rfind(u[5], "/")]
- if not prefixes.has_key(prefix):
- prefixes[prefix] = ""
- return prefixes
-
-def getUsers(filecontextdir):
- rc = commands.getstatusoutput("grep ^user %s/users" % filecontextdir)
- udict = {}
- if rc[0] == 0:
- ulist = rc[1].strip().split("\n")
- for u in ulist:
- user = u.split()
- try:
- if user[1] == "user_u" or user[1] == "system_u":
- continue
- # !!! chooses first role in the list to use in the file context !!!
- role = user[3]
- if role == "{":
- role = user[4]
- role = role.split("_r")[0]
- home = pwd.getpwnam(user[1])[5]
- if home == "/":
- continue
- prefs = {}
- prefs["role"] = role
- prefs["home"] = home
- udict[user[1]] = prefs
- except KeyError:
- sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user[1])
- return udict
-
-def update(filecontext, user, prefs):
- rc=commands.getstatusoutput("grep -h '^HOME_DIR' %s | grep -v vmware | sed -e 's|HOME_DIR|%s|' -e 's/ROLE/%s/' -e 's/system_u/%s/'" % (filecontext, prefs["home"], prefs["role"], user))
- if rc[0] == 0:
- print rc[1]
- else:
- errorExit(string.join("grep/sed error ", rc[1]))
- return rc
-
-def oldgenhomedircon(filecontextdir, filecontext):
- sys.stderr.write("Using genhomedircon in this fashion is supported for backwards compatability\n")
- sys.stderr.write("Please update to the latest policy\n")
- sys.stderr.flush()
-
- if os.path.isdir(filecontextdir) == 0:
- sys.stderr.write("New usage is the following\n")
- usage()
- #We are going to define home directory used by libuser and show-utils as a home directory root
- prefixes = {}
- rc=commands.getstatusoutput("grep -h '^HOME' /etc/default/useradd")
- if rc[0] == 0:
- homedir = rc[1].split("=")[1]
- homedir = homedir.split("#")[0]
- homedir = homedir.strip()
- if not prefixes.has_key(homedir):
- prefixes[homedir] = ""
- else:
- #rc[0] == 256 means the file was there, we read it, but the grep didn't match
- if rc[0] != 256:
- sys.stderr.write("%s\n" % rc[1])
- sys.stderr.write("You do not have access to /etc/default/useradd HOME=\n")
- sys.stderr.flush()
-
-
- rc=commands.getstatusoutput("grep -h '^LU_HOMEDIRECTORY' /etc/libuser.conf")
- if rc[0] == 0:
- homedir = rc[1].split("=")[1]
- homedir = homedir.split("#")[0]
- homedir = homedir.strip()
- homedir = re.sub(r"[^/a-zA-Z0-9].*$", "", homedir)
- if not prefixes.has_key(homedir):
- prefixes[homedir] = ""
- else:
- if rc[0] != 256:
- sys.stderr.write("%s\n" % rc[1])
- sys.stderr.write("You do not have access to /etc/libuser.conf LU_HOMEDIRECTORY=\n")
- sys.stderr.flush()
-
- #the idea is that we need to find all of the home_root_t directories we do this by just accepting
- #any default home directory defined by either /etc/libuser.conf or /etc/default/useradd
- #we then get the potential home directory roots from /etc/passwd or nis or whereever and look at
- #the defined homedir for all users with UID > STARTING_UID. This list of possible root homedirs
- #is then checked to see if it has an explicite context defined in the file_contexts. Explicit
- #is any regex that would match it which does not end with .*$ or .+$ since those are general
- #recursive matches. We then take any regex which ends with [pattern](/.*)?$ and just check against
- #[pattern]
- potential_prefixes = getPrefixes()
- prefix_regex = {}
- #this works by grepping the file_contexts for
- # 1. ^/ makes sure this is not a comment
- # 2. prints only the regex in the first column first cut on \t then on space
- rc=commands.getstatusoutput("grep \"^/\" %s | cut -f 1 | cut -f 1 -d \" \" " % (sys.argv[2]) )
- if rc[0] == 0:
- prefix_regex = rc[1].split("\n")
- else:
- sys.stderr.write("%s\n" % rc[1])
- sys.stderr.write("You do not have access to grep/cut/the file contexts\n")
- sys.stderr.flush()
- for potential in potential_prefixes.keys():
- addme = 1
- for regex in prefix_regex:
- #match a trailing (/*)? which is actually a bug in rpc_pipefs
- regex = re.sub("\(/\*\)\?$", "", regex)
- #match a trailing .+
- regex = re.sub("\.+$", "", regex)
- #match a trailing .*
- regex = re.sub("\.\*$", "", regex)
- #strip a (/.*)? which matches anything trailing to a /*$ which matches trailing /'s
- regex = re.sub("\(\/\.\*\)\?", "", regex)
- regex = regex + "/*$"
- if re.search(regex, potential, 0):
- addme = 0
- if addme == 1:
- if not prefixes.has_key(potential):
- prefixes[potential] = ""
-
-
- if prefixes.__eq__({}):
- sys.stderr.write("LU_HOMEDIRECTORY not set in /etc/libuser.conf\n")
- sys.stderr.write("HOME= not set in /etc/default/useradd\n")
- sys.stderr.write("And no users with a reasonable homedir found in passwd/nis/ldap/etc...\n")
- sys.stderr.write("Assuming /home is the root of home directories\n")
- sys.stderr.flush()
- prefixes["/home"] = ""
-
- # There may be a more elegant sed script to expand a macro to multiple lines, but this works
- sed_root = "h; s|^HOME_ROOT|%s|" % (string.join(prefixes.keys(), "|; p; g; s|^HOME_ROOT|"),)
- sed_dir = "h; s|^HOME_DIR|%s/[^/]+|; s|ROLE_|user_|" % (string.join(prefixes.keys(), "/[^/]+|; s|ROLE_|user_|; p; g; s|^HOME_DIR|"),)
-
- # Fill in HOME_ROOT, HOME_DIR, and ROLE for users not explicitly defined in /etc/security/selinux/src/policy/users
- rc=commands.getstatusoutput("sed -e \"/^HOME_ROOT/{%s}\" -e \"/^HOME_DIR/{%s}\" %s" % (sed_root, sed_dir, filecontext))
- if rc[0] == 0:
- print rc[1]
- else:
- errorExit(string.join("sed error ", rc[1]))
-
- users = getUsers(filecontextdir)
- print "\n#\n# User-specific file contexts\n#\n"
-
- # Fill in HOME and ROLE for users that are defined
- for u in users.keys():
- update(filecontext, u, users[u])
-
-#############################################################################
-#
-# End of backwards compatability section
-#
-#############################################################################
-
def getDefaultHomeDir():
ret = []
rc=commands.getstatusoutput("grep -h '^HOME' /etc/default/useradd")
@@ -287,6 +111,11 @@
class selinuxConfig:
def __init__(self, selinuxdir="/etc/selinux", type="targeted", usepwd=1):
+ self.semanageHandle=semanage_handle_create()
+ self.semanaged=semanage_is_managed(self.semanageHandle)
+ if self.semanaged:
+ semanage_connect(self.semanageHandle)
+ (status, self.ulist, self.usize) = semanage_user_list(self.semanageHandle)
self.type=type
self.selinuxdir=selinuxdir +"/"
self.contextdir="/contexts"
@@ -313,47 +142,72 @@
errorExit(string.join("sed error ", rc[1]))
def getUsersFile(self):
- return self.selinuxdir+self.type+"/users/local.users"
+ if self.semanaged:
+ return self.selinuxdir+self.type+"module/active/seusers"
+ else:
+ return self.selinuxdir+self.type+"/seusers"
- def getSystemUsersFile(self):
- return self.selinuxdir+self.type+"/users/system.users"
-
def heading(self):
ret = "\n#\n#\n# User-specific file contexts, generated via %s\n" % sys.argv[0]
ret += "# edit %s to change file_context\n#\n#\n" % self.getUsersFile()
return ret
+
+ def defaultrole(self, name):
+ for idx in range(self.usize):
+ user = semanage_user_by_idx(self.ulist, idx)
+ if semanage_user_get_name(user) == name:
+ role=semanage_user_get_defrole(user)
+ if role=="system_r":
+ # targeted policy
+ return "user_r"
+ else:
+ return role
+ return name
+ def adduser(self, udict, user, seuser, role):
+ try:
+ if seuser == "user_u" or user == "__default__":
+ return
+ # !!! chooses first role in the list to use in the file context !!!
+ if role[-2:] == "_r" or role[-2:] == "_u":
+ role = role[:-2]
+ home = pwd.getpwnam(user)[5]
+ if home == "/":
+ return
+ prefs = {}
+ prefs["role"] = role
+ prefs["home"] = home
+ udict[seuser] = prefs
+ except KeyError:
+ sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user)
+
def getUsers(self):
- users=""
- rc = commands.getstatusoutput('grep "^user" %s' % self.getSystemUsersFile())
- if rc[0] == 0:
- users+=rc[1]+"\n"
- rc = commands.getstatusoutput("grep ^user %s" % self.getUsersFile())
- if rc[0] == 0:
- users+=rc[1]
udict = {}
- prefs = {}
- if users != "":
- ulist = users.split("\n")
+ if self.semanaged:
+ (status, list, lsize) = semanage_seuser_list(self.semanageHandle)
+ for idx in range(lsize):
+ user=[]
+ seuser = semanage_seuser_by_idx(list, idx)
+ seusername=semanage_seuser_get_sename(seuser)
+ self.adduser(udict, semanage_seuser_get_name(seuser), seusername, self.defaultrole(seusername))
+
+ else:
+ users=""
+ rc = commands.getstatusoutput("grep -v '^ *#' %s" % self.getUsersFile())
+ if rc[0] == 0 and rc[1] != "":
+ ulist = rc[1].split("\n")
+ print ulist
for u in ulist:
- user = u.split()
- try:
- if len(user)==0 or user[1] == "user_u" or user[1] == "system_u":
- continue
- # !!! chooses first role in the list to use in the file context !!!
- role = user[3]
- if role == "{":
- role = user[4]
- role = role.split("_r")[0]
- home = pwd.getpwnam(user[1])[5]
- if home == "/":
- continue
- prefs = {}
- prefs["role"] = role
- prefs["home"] = home
- udict[user[1]] = prefs
- except KeyError:
- sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user[1])
+ if len(u)==0:
+ continue
+ user = u.split(":")
+ if len(user) < 3:
+ continue
+ if user[0] == "root":
+ role="user"
+ else:
+ role=user[0]
+ self.adduser(udict, user[0], user[1], role)
return udict
def getHomeDirContext(self, user, home, role):
@@ -362,9 +216,8 @@
return ret + rc[1] + "\n"
def getUserContext(self, user, sel_user, role):
- ret="\n\n#\n# Other Context for user %s\n#\n\n" % user
rc=commands.getstatusoutput("grep 'USER' %s | sed -e 's/USER/%s/' -e 's/ROLE/%s/' -e 's/system_u/%s/'" % (self.getHomeDirTemplate(), user, role, sel_user))
- return ret + rc[1] + "\n"
+ return rc[1] + "\n"
def genHomeDirContext(self):
users = self.getUsers()
@@ -478,10 +331,6 @@
if type==None:
type=getSELinuxType(directory)
- if len(cmds) == 2:
- oldgenhomedircon(cmds[0], cmds[1])
- sys.exit(0)
-
if len(cmds) != 0:
usage()
selconf=selinuxConfig(directory, type, usepwd)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 16:17 ` rawhide targeted vs. refpolicy rpm Daniel J Walsh
@ 2005-11-14 16:51 ` Stephen Smalley
2005-11-14 18:23 ` Daniel J Walsh
2005-11-14 16:59 ` Joshua Brindle
2005-11-14 17:28 ` Ivan Gyurdiev
2 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-14 16:51 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: SELinux-dev, SE Linux
On Mon, 2005-11-14 at 11:17 -0500, Daniel J Walsh wrote:
> policycoreutils patch to genhomedircon to use libsemanage to read
> seusers file.
A couple of concerns about upstreaming this patch as is:
1) Compatibility. In addition to dropping compatibility with the older
usage of genhomedircon from FC3, the patch also doesn't provide any
backward compatibility for the older system.users/local.users-based
generation, and requires that the new seusers file be present. Is that
ok? I suppose that genhomedircon is somewhat of an SELinux-internal
helper at this point (only used by other core SELinux components like
the policy Makefile and libsemanage), so as long as people don't try to
install the latest policycoreutils on earlier systems without also
updating their policy to a corresponding version, they shouldn't have a
problem.
2) Targeted policy specialization. defaultrole() has a hack for
targeted policy to remap system_r to user_r as the default role for a
user when system_r is returned by semanage, and getUsers() has a
targeted policy-specific hack to handle the root entry in seusers when
not using semanage. The latter will break anyone with strict policy
that isn't converted to using semanage.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 16:17 ` rawhide targeted vs. refpolicy rpm Daniel J Walsh
2005-11-14 16:51 ` Stephen Smalley
@ 2005-11-14 16:59 ` Joshua Brindle
2005-11-14 18:27 ` Daniel J Walsh
2005-11-14 17:28 ` Ivan Gyurdiev
2 siblings, 1 reply; 30+ messages in thread
From: Joshua Brindle @ 2005-11-14 16:59 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, SE Linux
Daniel J Walsh wrote:
> policycoreutils patch to genhomedircon to use libsemanage to read
> seusers file.
>
>
<snip>
>
> class selinuxConfig:
> def __init__(self, selinuxdir="/etc/selinux", type="targeted", usepwd=1):
> + self.semanageHandle=semanage_handle_create()
> + self.semanaged=semanage_is_managed(self.semanageHandle)
> + if self.semanaged:
> + semanage_connect(self.semanageHandle)
> + (status, self.ulist, self.usize) = semanage_user_list(self.semanageHandle)
> self.type=type
> self.selinuxdir=selinuxdir +"/"
> self.contextdir="/contexts"
> @@ -313,47 +142,72 @@
> errorExit(string.join("sed error ", rc[1]))
>
> def getUsersFile(self):
> - return self.selinuxdir+self.type+"/users/local.users"
> + if self.semanaged:
> + return self.selinuxdir+self.type+"module/active/seusers"
Why should this return a path at all in the managed case? genhomedircon
(or any semanage user) can't make an assumption that a particular path
is used, accessible or even on the same computer.
> + else:
> + return self.selinuxdir+self.type+"/seusers"
>
> - def getSystemUsersFile(self):
> - return self.selinuxdir+self.type+"/users/system.users"
> -
> def heading(self):
> ret = "\n#\n#\n# User-specific file contexts, generated via %s\n" % sys.argv[0]
> ret += "# edit %s to change file_context\n#\n#\n" % self.getUsersFile()
> return ret
>
> +
> + def defaultrole(self, name):
> + for idx in range(self.usize):
> + user = semanage_user_by_idx(self.ulist, idx)
> + if semanage_user_get_name(user) == name:
> + role=semanage_user_get_defrole(user)
> + if role=="system_r":
> + # targeted policy
> + return "user_r"
I don't understand this case. Why wouldn't user_get_defrole return
user_r in the targeted case?
> + else:
> + return role
> + return name
> + def adduser(self, udict, user, seuser, role):
> + try:
> + if seuser == "user_u" or user == "__default__":
> + return
> + # !!! chooses first role in the list to use in the file context !!!
or what semanage considers the default role, right?
> + if role[-2:] == "_r" or role[-2:] == "_u":
> + role = role[:-2]
> + home = pwd.getpwnam(user)[5]
> + if home == "/":
> + return
> + prefs = {}
> + prefs["role"] = role
> + prefs["home"] = home
> + udict[seuser] = prefs
> + except KeyError:
> + sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user)
> +
<snip>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 16:17 ` rawhide targeted vs. refpolicy rpm Daniel J Walsh
2005-11-14 16:51 ` Stephen Smalley
2005-11-14 16:59 ` Joshua Brindle
@ 2005-11-14 17:28 ` Ivan Gyurdiev
2 siblings, 0 replies; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-14 17:28 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Stephen Smalley, SE Linux, Joshua Brindle
Joshua Brindle wrote:
> This adds wrappers for some functions in libsemanage. The only wrapped
> interfaces at this point are query functions for modules, seuser, and
> user's. These should be sufficient for genhomedircon, and we can add
> more wrapped interfaces as necessary.
Daniel J Walsh wrote:
> policycoreutils patch to genhomedircon to use libsemanage to read
> seusers file.
This is awesome - the library has users!
I guess that means I should stop changing the API now :)
Genhomedircon dependency on file backend will be gone. It will no longer
knows about the format of the files (or whether they are files at
all)... or about the first role being the default role (now libsemanage
decides that, and if you call set_defrole it makes sure that one is
written first in the file).
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* I have modified Joshua's libsemanage-swigify patch to work better in my spec file
[not found] ` <1131983537.5415.137.camel@moss-spartans.epoch.ncsc.mil>
2005-11-14 16:17 ` rawhide targeted vs. refpolicy rpm Daniel J Walsh
@ 2005-11-14 18:09 ` Daniel J Walsh
2005-11-15 13:21 ` Stephen Smalley
1 sibling, 1 reply; 30+ messages in thread
From: Daniel J Walsh @ 2005-11-14 18:09 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Chad Sellers, Joshua Brindle, SE Linux
swigify patch
ftp://people.redhat.com/dwalsh/SELinux/libsemanage-swigify.patch
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 16:51 ` Stephen Smalley
@ 2005-11-14 18:23 ` Daniel J Walsh
2005-11-14 19:32 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Daniel J Walsh @ 2005-11-14 18:23 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux-dev, SE Linux
[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]
Stephen Smalley wrote:
> On Mon, 2005-11-14 at 11:17 -0500, Daniel J Walsh wrote:
>
>> policycoreutils patch to genhomedircon to use libsemanage to read
>> seusers file.
>>
>
> A couple of concerns about upstreaming this patch as is:
> 1) Compatibility. In addition to dropping compatibility with the older
> usage of genhomedircon from FC3, the patch also doesn't provide any
> backward compatibility for the older system.users/local.users-based
> generation, and requires that the new seusers file be present. Is that
> ok? I suppose that genhomedircon is somewhat of an SELinux-internal
> helper at this point (only used by other core SELinux components like
> the policy Makefile and libsemanage), so as long as people don't try to
> install the latest policycoreutils on earlier systems without also
> updating their policy to a corresponding version, they shouldn't have a
> problem.
>
I don't believe anyone uses this method at present other than the
developers so I didn't see this as a necessity to maintain.
> 2) Targeted policy specialization. defaultrole() has a hack for
> targeted policy to remap system_r to user_r as the default role for a
> user when system_r is returned by semanage, and getUsers() has a
> targeted policy-specific hack to handle the root entry in seusers when
> not using semanage. The latter will break anyone with strict policy
> that isn't converted to using semanage.
>
>
I thought in strict policy this would be a bug also. Since it should be
returning something like staff_r or user_r.
The previous patch had a problem on non libsemanaged machines.
--
[-- Attachment #2: policycoreutils-rhat.patch --]
[-- Type: text/x-patch, Size: 13799 bytes --]
diff --exclude-from=exclude -N -u -r nsapolicycoreutils/scripts/genhomedircon policycoreutils-1.27.27/scripts/genhomedircon
--- nsapolicycoreutils/scripts/genhomedircon 2005-09-12 16:33:30.000000000 -0400
+++ policycoreutils-1.27.27/scripts/genhomedircon 2005-11-14 12:58:49.000000000 -0500
@@ -15,32 +15,19 @@
# The file CONTEXTDIR/files/homedir_template exists. This file is used to
# set up the home directory context for each real user.
#
-# If a user has more than one role in CONTEXTDIR/local.users, genhomedircon uses
-# the first role in the list.
+# If a user has more than one role, genhomedircon uses the first role in the list.
#
-# If a user is not listed in CONTEXTDIR/local.users, he will default to user_u, role user
+# If a user is not listed in CONTEXTDIR/seusers, he will default to user_u, role user
#
# "Real" users (as opposed to system users) are those whose UID is greater than
# or equal STARTING_UID (usually 500) and whose login is not a member of
-# EXCLUDE_LOGINS. Users who are explicitly defined in CONTEXTDIR/local.users
+# EXCLUDE_LOGINS. Users who are explicitly defined in CONTEXTDIR/seusers
# are always "real" (including root, in the default configuration).
#
#
-# Old ASSUMPTIONS:
-#
-# If a user has more than one role in FILECONTEXTDIR/users, genhomedircon uses
-# the first role in the list.
-#
-# If a user is not listed in FILECONTEXTDIR/users, genhomedircon assumes that
-# the user's home dir will be found in one of the HOME_ROOTs.
-#
-# "Real" users (as opposed to system users) are those whose UID is greater than
-# or equal STARTING_UID (usually 500) and whose login is not a member of
-# EXCLUDE_LOGINS. Users who are explicitly defined in FILECONTEXTDIR/users
-# are always "real" (including root, in the default configuration).
-#
import commands, sys, os, pwd, string, getopt, re
+from semanage import *;
EXCLUDE_LOGINS=["/sbin/nologin", "/bin/false"]
@@ -67,169 +54,6 @@
starting_uid = 500
return starting_uid
-#############################################################################
-#
-# This section is just for backwards compatability
-#
-#############################################################################
-def getPrefixes():
- ulist = pwd.getpwall()
- STARTING_UID=getStartingUID()
- prefixes = {}
- for u in ulist:
- if u[2] >= STARTING_UID and \
- not u[6] in EXCLUDE_LOGINS and \
- u[5] != "/" and \
- string.count(u[5], "/") > 1:
- prefix = u[5][:string.rfind(u[5], "/")]
- if not prefixes.has_key(prefix):
- prefixes[prefix] = ""
- return prefixes
-
-def getUsers(filecontextdir):
- rc = commands.getstatusoutput("grep ^user %s/users" % filecontextdir)
- udict = {}
- if rc[0] == 0:
- ulist = rc[1].strip().split("\n")
- for u in ulist:
- user = u.split()
- try:
- if user[1] == "user_u" or user[1] == "system_u":
- continue
- # !!! chooses first role in the list to use in the file context !!!
- role = user[3]
- if role == "{":
- role = user[4]
- role = role.split("_r")[0]
- home = pwd.getpwnam(user[1])[5]
- if home == "/":
- continue
- prefs = {}
- prefs["role"] = role
- prefs["home"] = home
- udict[user[1]] = prefs
- except KeyError:
- sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user[1])
- return udict
-
-def update(filecontext, user, prefs):
- rc=commands.getstatusoutput("grep -h '^HOME_DIR' %s | grep -v vmware | sed -e 's|HOME_DIR|%s|' -e 's/ROLE/%s/' -e 's/system_u/%s/'" % (filecontext, prefs["home"], prefs["role"], user))
- if rc[0] == 0:
- print rc[1]
- else:
- errorExit(string.join("grep/sed error ", rc[1]))
- return rc
-
-def oldgenhomedircon(filecontextdir, filecontext):
- sys.stderr.write("Using genhomedircon in this fashion is supported for backwards compatability\n")
- sys.stderr.write("Please update to the latest policy\n")
- sys.stderr.flush()
-
- if os.path.isdir(filecontextdir) == 0:
- sys.stderr.write("New usage is the following\n")
- usage()
- #We are going to define home directory used by libuser and show-utils as a home directory root
- prefixes = {}
- rc=commands.getstatusoutput("grep -h '^HOME' /etc/default/useradd")
- if rc[0] == 0:
- homedir = rc[1].split("=")[1]
- homedir = homedir.split("#")[0]
- homedir = homedir.strip()
- if not prefixes.has_key(homedir):
- prefixes[homedir] = ""
- else:
- #rc[0] == 256 means the file was there, we read it, but the grep didn't match
- if rc[0] != 256:
- sys.stderr.write("%s\n" % rc[1])
- sys.stderr.write("You do not have access to /etc/default/useradd HOME=\n")
- sys.stderr.flush()
-
-
- rc=commands.getstatusoutput("grep -h '^LU_HOMEDIRECTORY' /etc/libuser.conf")
- if rc[0] == 0:
- homedir = rc[1].split("=")[1]
- homedir = homedir.split("#")[0]
- homedir = homedir.strip()
- homedir = re.sub(r"[^/a-zA-Z0-9].*$", "", homedir)
- if not prefixes.has_key(homedir):
- prefixes[homedir] = ""
- else:
- if rc[0] != 256:
- sys.stderr.write("%s\n" % rc[1])
- sys.stderr.write("You do not have access to /etc/libuser.conf LU_HOMEDIRECTORY=\n")
- sys.stderr.flush()
-
- #the idea is that we need to find all of the home_root_t directories we do this by just accepting
- #any default home directory defined by either /etc/libuser.conf or /etc/default/useradd
- #we then get the potential home directory roots from /etc/passwd or nis or whereever and look at
- #the defined homedir for all users with UID > STARTING_UID. This list of possible root homedirs
- #is then checked to see if it has an explicite context defined in the file_contexts. Explicit
- #is any regex that would match it which does not end with .*$ or .+$ since those are general
- #recursive matches. We then take any regex which ends with [pattern](/.*)?$ and just check against
- #[pattern]
- potential_prefixes = getPrefixes()
- prefix_regex = {}
- #this works by grepping the file_contexts for
- # 1. ^/ makes sure this is not a comment
- # 2. prints only the regex in the first column first cut on \t then on space
- rc=commands.getstatusoutput("grep \"^/\" %s | cut -f 1 | cut -f 1 -d \" \" " % (sys.argv[2]) )
- if rc[0] == 0:
- prefix_regex = rc[1].split("\n")
- else:
- sys.stderr.write("%s\n" % rc[1])
- sys.stderr.write("You do not have access to grep/cut/the file contexts\n")
- sys.stderr.flush()
- for potential in potential_prefixes.keys():
- addme = 1
- for regex in prefix_regex:
- #match a trailing (/*)? which is actually a bug in rpc_pipefs
- regex = re.sub("\(/\*\)\?$", "", regex)
- #match a trailing .+
- regex = re.sub("\.+$", "", regex)
- #match a trailing .*
- regex = re.sub("\.\*$", "", regex)
- #strip a (/.*)? which matches anything trailing to a /*$ which matches trailing /'s
- regex = re.sub("\(\/\.\*\)\?", "", regex)
- regex = regex + "/*$"
- if re.search(regex, potential, 0):
- addme = 0
- if addme == 1:
- if not prefixes.has_key(potential):
- prefixes[potential] = ""
-
-
- if prefixes.__eq__({}):
- sys.stderr.write("LU_HOMEDIRECTORY not set in /etc/libuser.conf\n")
- sys.stderr.write("HOME= not set in /etc/default/useradd\n")
- sys.stderr.write("And no users with a reasonable homedir found in passwd/nis/ldap/etc...\n")
- sys.stderr.write("Assuming /home is the root of home directories\n")
- sys.stderr.flush()
- prefixes["/home"] = ""
-
- # There may be a more elegant sed script to expand a macro to multiple lines, but this works
- sed_root = "h; s|^HOME_ROOT|%s|" % (string.join(prefixes.keys(), "|; p; g; s|^HOME_ROOT|"),)
- sed_dir = "h; s|^HOME_DIR|%s/[^/]+|; s|ROLE_|user_|" % (string.join(prefixes.keys(), "/[^/]+|; s|ROLE_|user_|; p; g; s|^HOME_DIR|"),)
-
- # Fill in HOME_ROOT, HOME_DIR, and ROLE for users not explicitly defined in /etc/security/selinux/src/policy/users
- rc=commands.getstatusoutput("sed -e \"/^HOME_ROOT/{%s}\" -e \"/^HOME_DIR/{%s}\" %s" % (sed_root, sed_dir, filecontext))
- if rc[0] == 0:
- print rc[1]
- else:
- errorExit(string.join("sed error ", rc[1]))
-
- users = getUsers(filecontextdir)
- print "\n#\n# User-specific file contexts\n#\n"
-
- # Fill in HOME and ROLE for users that are defined
- for u in users.keys():
- update(filecontext, u, users[u])
-
-#############################################################################
-#
-# End of backwards compatability section
-#
-#############################################################################
-
def getDefaultHomeDir():
ret = []
rc=commands.getstatusoutput("grep -h '^HOME' /etc/default/useradd")
@@ -287,6 +111,11 @@
class selinuxConfig:
def __init__(self, selinuxdir="/etc/selinux", type="targeted", usepwd=1):
+ self.semanageHandle=semanage_handle_create()
+ self.semanaged=semanage_is_managed(self.semanageHandle)
+ if self.semanaged:
+ semanage_connect(self.semanageHandle)
+ (status, self.ulist, self.usize) = semanage_user_list(self.semanageHandle)
self.type=type
self.selinuxdir=selinuxdir +"/"
self.contextdir="/contexts"
@@ -313,47 +142,70 @@
errorExit(string.join("sed error ", rc[1]))
def getUsersFile(self):
- return self.selinuxdir+self.type+"/users/local.users"
+ if self.semanaged:
+ return self.selinuxdir+self.type+"module/active/seusers"
+ else:
+ return self.selinuxdir+self.type+"/seusers"
- def getSystemUsersFile(self):
- return self.selinuxdir+self.type+"/users/system.users"
-
def heading(self):
ret = "\n#\n#\n# User-specific file contexts, generated via %s\n" % sys.argv[0]
ret += "# edit %s to change file_context\n#\n#\n" % self.getUsersFile()
return ret
+
+ def defaultrole(self, name):
+ for idx in range(self.usize):
+ user = semanage_user_by_idx(self.ulist, idx)
+ if semanage_user_get_name(user) == name:
+ role=semanage_user_get_defrole(user)
+ if role=="system_r":
+ # targeted policy
+ return "user_r"
+ else:
+ return role
+ return name
+ def adduser(self, udict, user, seuser, role):
+ try:
+ if seuser == "user_u" or user == "__default__":
+ return
+ # !!! chooses first role in the list to use in the file context !!!
+ if role[-2:] == "_r" or role[-2:] == "_u":
+ role = role[:-2]
+ home = pwd.getpwnam(user)[5]
+ if home == "/":
+ return
+ prefs = {}
+ prefs["role"] = role
+ prefs["home"] = home
+ udict[seuser] = prefs
+ except KeyError:
+ sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user)
+
def getUsers(self):
- users=""
- rc = commands.getstatusoutput('grep "^user" %s' % self.getSystemUsersFile())
- if rc[0] == 0:
- users+=rc[1]+"\n"
- rc = commands.getstatusoutput("grep ^user %s" % self.getUsersFile())
- if rc[0] == 0:
- users+=rc[1]
udict = {}
- prefs = {}
- if users != "":
- ulist = users.split("\n")
- for u in ulist:
- user = u.split()
- try:
- if len(user)==0 or user[1] == "user_u" or user[1] == "system_u":
+ if self.semanaged:
+ (status, list, lsize) = semanage_seuser_list(self.semanageHandle)
+ for idx in range(lsize):
+ user=[]
+ seuser = semanage_seuser_by_idx(list, idx)
+ seusername=semanage_seuser_get_sename(seuser)
+ self.adduser(udict, semanage_seuser_get_name(seuser), seusername, self.defaultrole(seusername))
+
+ else:
+ rc = commands.getstatusoutput("grep -v '^ *#' %s" % self.getUsersFile())
+ if rc[0] == 0 and rc[1] != "":
+ ulist = rc[1].split("\n")
+ for u in ulist:
+ if len(u)==0:
continue
- # !!! chooses first role in the list to use in the file context !!!
- role = user[3]
- if role == "{":
- role = user[4]
- role = role.split("_r")[0]
- home = pwd.getpwnam(user[1])[5]
- if home == "/":
+ user = u.split(":")
+ if len(user) < 3:
continue
- prefs = {}
- prefs["role"] = role
- prefs["home"] = home
- udict[user[1]] = prefs
- except KeyError:
- sys.stderr.write("The user \"%s\" is not present in the passwd file, skipping...\n" % user[1])
+ if user[0] == "root":
+ role="user"
+ else:
+ role=user[0]
+ self.adduser(udict, user[0], user[1], role)
return udict
def getHomeDirContext(self, user, home, role):
@@ -362,9 +214,8 @@
return ret + rc[1] + "\n"
def getUserContext(self, user, sel_user, role):
- ret="\n\n#\n# Other Context for user %s\n#\n\n" % user
rc=commands.getstatusoutput("grep 'USER' %s | sed -e 's/USER/%s/' -e 's/ROLE/%s/' -e 's/system_u/%s/'" % (self.getHomeDirTemplate(), user, role, sel_user))
- return ret + rc[1] + "\n"
+ return rc[1] + "\n"
def genHomeDirContext(self):
users = self.getUsers()
@@ -478,10 +329,6 @@
if type==None:
type=getSELinuxType(directory)
- if len(cmds) == 2:
- oldgenhomedircon(cmds[0], cmds[1])
- sys.exit(0)
-
if len(cmds) != 0:
usage()
selconf=selinuxConfig(directory, type, usepwd)
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 16:59 ` Joshua Brindle
@ 2005-11-14 18:27 ` Daniel J Walsh
2005-11-14 19:37 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Daniel J Walsh @ 2005-11-14 18:27 UTC (permalink / raw)
To: Joshua Brindle; +Cc: Stephen Smalley, SE Linux
Joshua Brindle wrote:
> Daniel J Walsh wrote:
>> policycoreutils patch to genhomedircon to use libsemanage to read
>> seusers file.
>>
>>
> <snip>
>>
>> class selinuxConfig:
>> def __init__(self, selinuxdir="/etc/selinux", type="targeted",
>> usepwd=1):
>> + self.semanageHandle=semanage_handle_create()
>> + self.semanaged=semanage_is_managed(self.semanageHandle)
>> + if self.semanaged:
>> + semanage_connect(self.semanageHandle)
>> + (status, self.ulist, self.usize) =
>> semanage_user_list(self.semanageHandle)
>> self.type=type
>> self.selinuxdir=selinuxdir +"/"
>> self.contextdir="/contexts"
>> @@ -313,47 +142,72 @@
>> errorExit(string.join("sed error ", rc[1]))
>>
>> def getUsersFile(self):
>> - return self.selinuxdir+self.type+"/users/local.users"
>> + if self.semanaged:
>> + return self.selinuxdir+self.type+"module/active/seusers"
> Why should this return a path at all in the managed case?
> genhomedircon (or any semanage user) can't make an assumption that a
> particular path is used, accessible or even on the same computer.
Ok I guess we could throw an exception.
>
>> + else:
>> + return self.selinuxdir+self.type+"/seusers"
>>
>> - def getSystemUsersFile(self):
>> - return self.selinuxdir+self.type+"/users/system.users"
>> -
>> def heading(self):
>> ret = "\n#\n#\n# User-specific file contexts, generated via
>> %s\n" % sys.argv[0]
>> ret += "# edit %s to change file_context\n#\n#\n" %
>> self.getUsersFile()
>> return ret
>>
>> +
>> + def defaultrole(self, name):
>> + for idx in range(self.usize):
>> + user = semanage_user_by_idx(self.ulist, idx)
>> + if semanage_user_get_name(user) == name:
>> + role=semanage_user_get_defrole(user)
>> + if role=="system_r":
>> + # targeted policy
>> + return "user_r"
> I don't understand this case. Why wouldn't user_get_defrole return
> user_r in the targeted case?
>
user_r is not defined in targeted policy. Everything runs in one role
system_r. Problem is we don't use system_home_t.
>> + else:
>> + return role
>> + return name
>> + def adduser(self, udict, user, seuser, role):
>> + try:
>> + if seuser == "user_u" or user == "__default__":
>> + return
>> + # !!! chooses first role in the list to use in the file
>> context !!!
> or what semanage considers the default role, right?
>
>> + if role[-2:] == "_r" or role[-2:] == "_u":
>> + role = role[:-2]
>> + home = pwd.getpwnam(user)[5]
>> + if home == "/":
>> + return
>> + prefs = {}
>> + prefs["role"] = role
>> + prefs["home"] = home
>> + udict[seuser] = prefs
>> + except KeyError:
>> + sys.stderr.write("The user \"%s\" is not present in the
>> passwd file, skipping...\n" % user)
>> +
> <snip>
>
--
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 18:23 ` Daniel J Walsh
@ 2005-11-14 19:32 ` Stephen Smalley
2005-11-15 13:23 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-14 19:32 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, SE Linux
On Mon, 2005-11-14 at 13:23 -0500, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > A couple of concerns about upstreaming this patch as is:
> > 1) Compatibility.
> I don't believe anyone uses this method at present other than the
> developers so I didn't see this as a necessity to maintain.
Ok. Just be aware that if you ever push out an updated policycoreutils
to a prior release, you also need to update the policy package for that
release to use the new usage for genhomedircon and to include a seusers
file if you want it to continue working.
> > 2) Targeted policy specialization. defaultrole() has a hack for
> > targeted policy to remap system_r to user_r as the default role for a
> > user when system_r is returned by semanage, and getUsers() has a
> > targeted policy-specific hack to handle the root entry in seusers when
> > not using semanage. The latter will break anyone with strict policy
> > that isn't converted to using semanage.
> >
> >
> I thought in strict policy this would be a bug also. Since it should be
> returning something like staff_r or user_r.
> The previous patch had a problem on non libsemanaged machines.
Yes, but the current workaround doesn't generalize; it assumes root
defaults to user_r in the non-managed case, which isn't true under
strict policy. Options would seem to be:
- Drop support for non-managed systems from genhomedircon altogether, or
- Have genhomedircon fall back to looking for system.users if the system
is not managed, and use that to determine the default role for root.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 18:27 ` Daniel J Walsh
@ 2005-11-14 19:37 ` Stephen Smalley
2005-11-15 11:17 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-14 19:37 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: SELinux-dev, Joshua Brindle, SE Linux
On Mon, 2005-11-14 at 13:27 -0500, Daniel J Walsh wrote:
> user_r is not defined in targeted policy. Everything runs in one role
> system_r. Problem is we don't use system_home_t.
Right, this suggests that semanage needs to provide the home directory
context to genhomedircon as well rather than having genhomedircon derive
it from the user's default role.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 19:37 ` Stephen Smalley
@ 2005-11-15 11:17 ` Stephen Smalley
2005-11-15 13:40 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 11:17 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
On Mon, 2005-11-14 at 14:37 -0500, Stephen Smalley wrote:
> On Mon, 2005-11-14 at 13:27 -0500, Daniel J Walsh wrote:
> > user_r is not defined in targeted policy. Everything runs in one role
> > system_r. Problem is we don't use system_home_t.
>
> Right, this suggests that semanage needs to provide the home directory
> context to genhomedircon as well rather than having genhomedircon derive
> it from the user's default role.
Actually, on second thought, this reflects a bug and possibly design
flaw in semanage/sepol, IIUC. Previously, genhomedircon was using the
first role listed in the users files as the "default role" for purposes
of labeling the home directory, but that was purely a convention; the
kernel policy has no concept of a default role for a user, only a list
of authorized roles. Role and domain selection at login time (or
similar events, like su) is performed by dynamically computing the set
of contexts reachable for the user from the security context of the
entrypoint process (e.g. local login, gdm, sshd, crond, etc) based on
policy and then ordering them based on the default_contexts
configuration file (which is not part of the kernel policy).
Since the kernel policy has no concept of a default role for the user,
the user_datum in libsepol merely stores an unordered set of authorized
roles; it doesn't preserve the ordering information from the users file
at all presently. The user_to_record() converter function in libsepol
merely processes the roles in the order in which they happen to be
stored in the ebitmap, which is just a reflection of the bit value
ordering of the roles. Thus, we are returning system_r rather than
user_r from sepol to semanage, and propagating that information to
genhomedircon. This is what led Dan to remapping system_r to user_r in
his genhomedircon patch.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: I have modified Joshua's libsemanage-swigify patch to work better in my spec file
2005-11-14 18:09 ` I have modified Joshua's libsemanage-swigify patch to work better in my spec file Daniel J Walsh
@ 2005-11-15 13:21 ` Stephen Smalley
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 13:21 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Chad Sellers, Joshua Brindle, SE Linux
On Mon, 2005-11-14 at 13:09 -0500, Daniel J Walsh wrote:
> swigify patch
>
> ftp://people.redhat.com/dwalsh/SELinux/libsemanage-swigify.patch
Thanks, merged into libsemanage as of 1.3.54.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-14 19:32 ` Stephen Smalley
@ 2005-11-15 13:23 ` Stephen Smalley
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 13:23 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, SE Linux
On Mon, 2005-11-14 at 14:32 -0500, Stephen Smalley wrote:
> Yes, but the current workaround doesn't generalize; it assumes root
> defaults to user_r in the non-managed case, which isn't true under
> strict policy. Options would seem to be:
> - Drop support for non-managed systems from genhomedircon altogether, or
> - Have genhomedircon fall back to looking for system.users if the system
> is not managed, and use that to determine the default role for root.
I see that you chose the latter option in the latest version of the
genhomedircon patch, which I've merged as of policycoreutils 1.27.28.
We still need to resolve the default role problem in semanage/sepol (at
which point we should be able to remove the current hack from
genhomedircon).
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 11:17 ` Stephen Smalley
@ 2005-11-15 13:40 ` Stephen Smalley
2005-11-15 14:44 ` Daniel J Walsh
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 13:40 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
On Tue, 2005-11-15 at 06:17 -0500, Stephen Smalley wrote:
> Actually, on second thought, this reflects a bug and possibly design
> flaw in semanage/sepol, IIUC. Previously, genhomedircon was using the
> first role listed in the users files as the "default role" for purposes
> of labeling the home directory, but that was purely a convention; the
> kernel policy has no concept of a default role for a user, only a list
> of authorized roles. Role and domain selection at login time (or
> similar events, like su) is performed by dynamically computing the set
> of contexts reachable for the user from the security context of the
> entrypoint process (e.g. local login, gdm, sshd, crond, etc) based on
> policy and then ordering them based on the default_contexts
> configuration file (which is not part of the kernel policy).
>
> Since the kernel policy has no concept of a default role for the user,
> the user_datum in libsepol merely stores an unordered set of authorized
> roles; it doesn't preserve the ordering information from the users file
> at all presently. The user_to_record() converter function in libsepol
> merely processes the roles in the order in which they happen to be
> stored in the ebitmap, which is just a reflection of the bit value
> ordering of the roles. Thus, we are returning system_r rather than
> user_r from sepol to semanage, and propagating that information to
> genhomedircon. This is what led Dan to remapping system_r to user_r in
> his genhomedircon patch.
So our options would seem to be:
- Make a change to the module format to explicitly record the "default"
role when a module is compiled from policy sources, so that libsepol can
correctly extract the defrole for the user and return it to libsemanage.
No need to change the kernel format AFAICS, as we only need this support
for modules, not the expanded policy. -or-
- Drop the notion of a defrole entirely from the sepol interface and
code, and handle determination of the default role for users defined in
the policy in semanage in some manner (possibly paralleling the logic
used by libselinux to compute the default context, but using the policy
object rather than the kernel to query reachable contexts, which
requires encapsulating and exporting the corresponding libsepol
interface).
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 13:40 ` Stephen Smalley
@ 2005-11-15 14:44 ` Daniel J Walsh
2005-11-15 14:57 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Daniel J Walsh @ 2005-11-15 14:44 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
Stephen Smalley wrote:
> On Tue, 2005-11-15 at 06:17 -0500, Stephen Smalley wrote:
>
>> Actually, on second thought, this reflects a bug and possibly design
>> flaw in semanage/sepol, IIUC. Previously, genhomedircon was using the
>> first role listed in the users files as the "default role" for purposes
>> of labeling the home directory, but that was purely a convention; the
>> kernel policy has no concept of a default role for a user, only a list
>> of authorized roles. Role and domain selection at login time (or
>> similar events, like su) is performed by dynamically computing the set
>> of contexts reachable for the user from the security context of the
>> entrypoint process (e.g. local login, gdm, sshd, crond, etc) based on
>> policy and then ordering them based on the default_contexts
>> configuration file (which is not part of the kernel policy).
>>
>> Since the kernel policy has no concept of a default role for the user,
>> the user_datum in libsepol merely stores an unordered set of authorized
>> roles; it doesn't preserve the ordering information from the users file
>> at all presently. The user_to_record() converter function in libsepol
>> merely processes the roles in the order in which they happen to be
>> stored in the ebitmap, which is just a reflection of the bit value
>> ordering of the roles. Thus, we are returning system_r rather than
>> user_r from sepol to semanage, and propagating that information to
>> genhomedircon. This is what led Dan to remapping system_r to user_r in
>> his genhomedircon patch.
>>
>
> So our options would seem to be:
> - Make a change to the module format to explicitly record the "default"
> role when a module is compiled from policy sources, so that libsepol can
> correctly extract the defrole for the user and return it to libsemanage.
> No need to change the kernel format AFAICS, as we only need this support
> for modules, not the expanded policy. -or-
> - Drop the notion of a defrole entirely from the sepol interface and
> code, and handle determination of the default role for users defined in
> the policy in semanage in some manner (possibly paralleling the logic
> used by libselinux to compute the default context, but using the policy
> object rather than the kernel to query reachable contexts, which
> requires encapsulating and exporting the corresponding libsepol
> interface).
>
>
I would think the latter, Some logic that takes into account what the
login program would do.
Since this also relies on the default_context file, correct?
--
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 14:44 ` Daniel J Walsh
@ 2005-11-15 14:57 ` Stephen Smalley
2005-11-15 15:10 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 14:57 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
On Tue, 2005-11-15 at 09:44 -0500, Daniel J Walsh wrote:
> > - Drop the notion of a defrole entirely from the sepol interface and
> > code, and handle determination of the default role for users defined in
> > the policy in semanage in some manner (possibly paralleling the logic
> > used by libselinux to compute the default context, but using the policy
> > object rather than the kernel to query reachable contexts, which
> > requires encapsulating and exporting the corresponding libsepol
> > interface).
> >
> >
> I would think the latter, Some logic that takes into account what the
> login program would do.
> Since this also relies on the default_context file, correct?
Yes. In the short term, we may be able to just use the default_contexts
file to find the first role listed there for login that is authorized
for the user. We don't want to call the libselinux interface
(get_default_context/get_ordered_context_list) itself, as that is based
on the currently running policy and libsemanage may be dealing with a
different policy at the time.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 14:57 ` Stephen Smalley
@ 2005-11-15 15:10 ` Stephen Smalley
2005-11-15 15:18 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 15:10 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
On Tue, 2005-11-15 at 09:57 -0500, Stephen Smalley wrote:
> On Tue, 2005-11-15 at 09:44 -0500, Daniel J Walsh wrote:
> > > - Drop the notion of a defrole entirely from the sepol interface and
> > > code, and handle determination of the default role for users defined in
> > > the policy in semanage in some manner (possibly paralleling the logic
> > > used by libselinux to compute the default context, but using the policy
> > > object rather than the kernel to query reachable contexts, which
> > > requires encapsulating and exporting the corresponding libsepol
> > > interface).
> > >
> > >
> > I would think the latter, Some logic that takes into account what the
> > login program would do.
> > Since this also relies on the default_context file, correct?
>
> Yes. In the short term, we may be able to just use the default_contexts
> file to find the first role listed there for login that is authorized
> for the user. We don't want to call the libselinux interface
> (get_default_context/get_ordered_context_list) itself, as that is based
> on the currently running policy and libsemanage may be dealing with a
> different policy at the time.
Hmmm...except that such an approach falls into the same problem as we
have now, i.e. default_contexts in targeted policy says
system_r:unconfined_t:s0 <MLS component is irrelevant there due to the
way in which MLS works these days>. Hence, semanage would still end up
returning system_r in the targeted policy case. The approach would work
in the strict policy case, as we have real user roles listed in its
default_contexts file, so it would just be a matter of finding the first
one that is authorized for the user in that case.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 15:10 ` Stephen Smalley
@ 2005-11-15 15:18 ` Stephen Smalley
2005-11-15 19:03 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 15:18 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
On Tue, 2005-11-15 at 10:10 -0500, Stephen Smalley wrote:
> Hmmm...except that such an approach falls into the same problem as we
> have now, i.e. default_contexts in targeted policy says
> system_r:unconfined_t:s0 <MLS component is irrelevant there due to the
> way in which MLS works these days>. Hence, semanage would still end up
> returning system_r in the targeted policy case. The approach would work
> in the strict policy case, as we have real user roles listed in its
> default_contexts file, so it would just be a matter of finding the first
> one that is authorized for the user in that case.
Ok, so perhaps what we need is a new semanage policy component that
provides libsemanage with:
a) default role (or use default_contexts to determine), and
b) home directory type prefix for that role, which can be different from
the role prefix itself.
And then have libsemanage export an interface to genhomedircon to obtain
the home directory type prefix for use in generating the file contexts
rather than using the role prefix itself.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 15:18 ` Stephen Smalley
@ 2005-11-15 19:03 ` Stephen Smalley
2005-11-15 19:28 ` Joshua Brindle
2005-11-15 19:50 ` Ivan Gyurdiev
0 siblings, 2 replies; 30+ messages in thread
From: Stephen Smalley @ 2005-11-15 19:03 UTC (permalink / raw)
To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, Joshua Brindle, SE Linux
On Tue, 2005-11-15 at 10:18 -0500, Stephen Smalley wrote:
> On Tue, 2005-11-15 at 10:10 -0500, Stephen Smalley wrote:
> > Hmmm...except that such an approach falls into the same problem as we
> > have now, i.e. default_contexts in targeted policy says
> > system_r:unconfined_t:s0 <MLS component is irrelevant there due to the
> > way in which MLS works these days>. Hence, semanage would still end up
> > returning system_r in the targeted policy case. The approach would work
> > in the strict policy case, as we have real user roles listed in its
> > default_contexts file, so it would just be a matter of finding the first
> > one that is authorized for the user in that case.
>
> Ok, so perhaps what we need is a new semanage policy component that
> provides libsemanage with:
> a) default role (or use default_contexts to determine), and
> b) home directory type prefix for that role, which can be different from
> the role prefix itself.
>
> And then have libsemanage export an interface to genhomedircon to obtain
> the home directory type prefix for use in generating the file contexts
> rather than using the role prefix itself.
Is there agreement on this direction? Is anyone working on this issue
yet?
One lingering question is whether sepol should retain its defrole
interfaces and record field for use by semanage for storing the defrole
in memory. semanage would then set up the defrole field for each user
entry from the policydb since sepol cannot provide that information.
Otherwise, we have to diverge the semanage user records from the sepol
user records, right?
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 19:03 ` Stephen Smalley
@ 2005-11-15 19:28 ` Joshua Brindle
2005-11-16 13:12 ` Stephen Smalley
2005-11-15 19:50 ` Ivan Gyurdiev
1 sibling, 1 reply; 30+ messages in thread
From: Joshua Brindle @ 2005-11-15 19:28 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, Ivan Gyurdiev, SELinux-dev, SE Linux
Stephen Smalley wrote:
> On Tue, 2005-11-15 at 10:18 -0500, Stephen Smalley wrote:
>
>>On Tue, 2005-11-15 at 10:10 -0500, Stephen Smalley wrote:
>>
>>>Hmmm...except that such an approach falls into the same problem as we
>>>have now, i.e. default_contexts in targeted policy says
>>>system_r:unconfined_t:s0 <MLS component is irrelevant there due to the
>>>way in which MLS works these days>. Hence, semanage would still end up
>>>returning system_r in the targeted policy case. The approach would work
>>>in the strict policy case, as we have real user roles listed in its
>>>default_contexts file, so it would just be a matter of finding the first
>>>one that is authorized for the user in that case.
>>
>>Ok, so perhaps what we need is a new semanage policy component that
>>provides libsemanage with:
>>a) default role (or use default_contexts to determine), and
>>b) home directory type prefix for that role, which can be different from
>>the role prefix itself.
>>
>>And then have libsemanage export an interface to genhomedircon to obtain
>>the home directory type prefix for use in generating the file contexts
>>rather than using the role prefix itself.
>
>
> Is there agreement on this direction? Is anyone working on this issue
> yet?
>
> One lingering question is whether sepol should retain its defrole
> interfaces and record field for use by semanage for storing the defrole
> in memory. semanage would then set up the defrole field for each user
> entry from the policydb since sepol cannot provide that information.
> Otherwise, we have to diverge the semanage user records from the sepol
> user records, right?
>
I agree, default role was always a loose concept. One question is how
the defaults are filled in, is this adding a new file to targeted/strict
that have default home directory prefixes?
This could just be implemented as another database type keyed on the
user, so that the sepol user records don't have to be modified.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 19:03 ` Stephen Smalley
2005-11-15 19:28 ` Joshua Brindle
@ 2005-11-15 19:50 ` Ivan Gyurdiev
2005-11-16 13:11 ` Stephen Smalley
1 sibling, 1 reply; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-15 19:50 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
>
>> Ok, so perhaps what we need is a new semanage policy component that
>> provides libsemanage with:
>> a) default role (or use default_contexts to determine), and
>> b) home directory type prefix for that role, which can be different from
>> the role prefix itself.
>>
>> And then have libsemanage export an interface to genhomedircon to obtain
>> the home directory type prefix for use in generating the file contexts
>> rather than using the role prefix itself.
>>
>
> Is there agreement on this direction? Is anyone working on this issue
> yet?
>
I am very confused..
1. The reason we designate a role as a "default" role is to get the
labeling prefix. If we already have the labeling prefix, why do we still
want to keep a "default" role around?
2. The labeling prefix has so far been tied to the user (map is
seuser->user->(fixed) role -> labeing prefix). Now you're saying the
login context should play a role in determining the labeling prefix? How
would this work? Which login context from default_contexts should be used?
3. Is there documentation on default_contexts, and how to work with it?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 19:50 ` Ivan Gyurdiev
@ 2005-11-16 13:11 ` Stephen Smalley
2005-11-16 13:42 ` Ivan Gyurdiev
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-16 13:11 UTC (permalink / raw)
To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
On Tue, 2005-11-15 at 14:50 -0500, Ivan Gyurdiev wrote:
> >
> >> Ok, so perhaps what we need is a new semanage policy component that
> >> provides libsemanage with:
> >> a) default role (or use default_contexts to determine), and
> >> b) home directory type prefix for that role, which can be different from
> >> the role prefix itself.
> >>
> >> And then have libsemanage export an interface to genhomedircon to obtain
> >> the home directory type prefix for use in generating the file contexts
> >> rather than using the role prefix itself.
> >>
> >
> > Is there agreement on this direction? Is anyone working on this issue
> > yet?
> >
>
> I am very confused..
>
> 1. The reason we designate a role as a "default" role is to get the
> labeling prefix. If we already have the labeling prefix, why do we still
> want to keep a "default" role around?
>
> 2. The labeling prefix has so far been tied to the user (map is
> seuser->user->(fixed) role -> labeing prefix). Now you're saying the
> login context should play a role in determining the labeling prefix? How
> would this work? Which login context from default_contexts should be used?
Good point. Let's just add a user->labelingprefix mapping and drop out
defrole altogether then.
> 3. Is there documentation on default_contexts, and how to work with it?
I suppose this becomes irrelevant given the above. I think it is
described in brief in the policy tech report, but not in great detail.
libselinux get_ordered_context_list is the "documentation" for how to
work with it.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-15 19:28 ` Joshua Brindle
@ 2005-11-16 13:12 ` Stephen Smalley
0 siblings, 0 replies; 30+ messages in thread
From: Stephen Smalley @ 2005-11-16 13:12 UTC (permalink / raw)
To: Joshua Brindle; +Cc: Daniel J Walsh, Ivan Gyurdiev, SELinux-dev, SE Linux
On Tue, 2005-11-15 at 14:28 -0500, Joshua Brindle wrote:
> I agree, default role was always a loose concept. One question is how
> the defaults are filled in, is this adding a new file to targeted/strict
> that have default home directory prefixes?
Yes, I think so.
> This could just be implemented as another database type keyed on the
> user, so that the sepol user records don't have to be modified.
Yes, good point. So we just drop defrole out of semanage and sepol user
interfaces altogether.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 13:11 ` Stephen Smalley
@ 2005-11-16 13:42 ` Ivan Gyurdiev
2005-11-16 13:42 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-16 13:42 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
>
>> I am very confused..
>>
>> 1. The reason we designate a role as a "default" role is to get the
>> labeling prefix. If we already have the labeling prefix, why do we still
>> want to keep a "default" role around?
>>
>> 2. The labeling prefix has so far been tied to the user (map is
>> seuser->user->(fixed) role -> labeing prefix). Now you're saying the
>> login context should play a role in determining the labeling prefix? How
>> would this work? Which login context from default_contexts should be used?
>>
>
> Good point. Let's just add a user->labelingprefix mapping and drop out
> defrole altogether then.
One thing I am still not clear about is why we need a labeling prefix
that's not related to a role.. how is targeted using the system role,
and labeling things with the user prefix? Isn't the whole point of the
labeling prefix to prevent that type of thing (cross-role communication).
Secondly, maybe we should look at the larger problem of why rbac doesn't
work, and do something about it. Dan keeps telling me how rbac should be
used to decide what programs users are allowed to run (depending on the
role they're in). However, it doesn't work that way, because those
programs store per-user files, and not per-role files. Selinux labels
per-role files differently to prevent cross-role communication (at
least, I assumed that's why), making the programs above not work. Is
polyinstatiation going to address this problem? Ideas...
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 13:42 ` Ivan Gyurdiev
@ 2005-11-16 13:42 ` Stephen Smalley
2005-11-16 14:08 ` Ivan Gyurdiev
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-16 13:42 UTC (permalink / raw)
To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
On Wed, 2005-11-16 at 08:42 -0500, Ivan Gyurdiev wrote:
> One thing I am still not clear about is why we need a labeling prefix
> that's not related to a role.. how is targeted using the system role,
> and labeling things with the user prefix? Isn't the whole point of the
> labeling prefix to prevent that type of thing (cross-role communication).
Targeted policy has no notion of user roles/domains. There is
effectively only one SELinux user identity and role in targeted policy;
the others are purely for compatibility with strict policy in file
contexts and application configuration files. Targeted policy only uses
TE domains to confine particular processes.
> Secondly, maybe we should look at the larger problem of why rbac doesn't
> work, and do something about it. Dan keeps telling me how rbac should be
> used to decide what programs users are allowed to run (depending on the
> role they're in). However, it doesn't work that way, because those
> programs store per-user files, and not per-role files. Selinux labels
> per-role files differently to prevent cross-role communication (at
> least, I assumed that's why), making the programs above not work. Is
> polyinstatiation going to address this problem? Ideas...
Yes, polyinstantiation is supposed to solve the problem of multiple
roles and multiple levels for a single user.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 13:42 ` Stephen Smalley
@ 2005-11-16 14:08 ` Ivan Gyurdiev
2005-11-16 14:14 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-16 14:08 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
>> One thing I am still not clear about is why we need a labeling prefix
>> that's not related to a role.. how is targeted using the system role,
>> and labeling things with the user prefix? Isn't the whole point of the
>> labeling prefix to prevent that type of thing (cross-role communication).
>>
>
> Targeted policy has no notion of user roles/domains. There is
> effectively only one SELinux user identity and role in targeted policy;
> the others are purely for compatibility with strict policy in file
> contexts and application configuration files. Targeted policy only uses
> TE domains to confine particular processes.
>
So why don't we label files in targeted as system_home_t, which seems
more correct and workaround this issue. The only change that seems
necessary to me is to move the defrole functions from sepol and into
semanage, since they don't do anything in sepol, and are misleading -
that would be additive divergence on the semanage side. If the user
wants to query sepol, and write records into semanage, he/she would have
to set the default role in addition to the other data.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 14:08 ` Ivan Gyurdiev
@ 2005-11-16 14:14 ` Stephen Smalley
2005-11-16 14:27 ` Ivan Gyurdiev
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-16 14:14 UTC (permalink / raw)
To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
On Wed, 2005-11-16 at 09:08 -0500, Ivan Gyurdiev wrote:
> >> One thing I am still not clear about is why we need a labeling prefix
> >> that's not related to a role.. how is targeted using the system role,
> >> and labeling things with the user prefix? Isn't the whole point of the
> >> labeling prefix to prevent that type of thing (cross-role communication).
> >>
> >
> > Targeted policy has no notion of user roles/domains. There is
> > effectively only one SELinux user identity and role in targeted policy;
> > the others are purely for compatibility with strict policy in file
> > contexts and application configuration files. Targeted policy only uses
> > TE domains to confine particular processes.
> >
> So why don't we label files in targeted as system_home_t, which seems
> more correct and workaround this issue. The only change that seems
> necessary to me is to move the defrole functions from sepol and into
> semanage, since they don't do anything in sepol, and are misleading -
> that would be additive divergence on the semanage side. If the user
> wants to query sepol, and write records into semanage, he/she would have
> to set the default role in addition to the other data.
Targeted policy and strict policy share many of the same macro
definitions, .te files, and .fc files, and we also want to allow easy
conversion from targeted to strict which means we want a high degree of
on-disk xattr compatibility. Using a different set of types on /home in
targeted would not be helpful there, although one might be able to work
around the issue via type aliases.
Even in semanage, defrole is potentially misleading, as the actual
default role is context-dependent, e.g. root can be set up to login as
staff_r by default for ssh logins (so that acquiring sysadm_r access
requires a further step via newrole or su) while logging in as sysadm_r
by default for console logins.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 14:27 ` Ivan Gyurdiev
@ 2005-11-16 14:26 ` Stephen Smalley
2005-11-16 14:47 ` Ivan Gyurdiev
0 siblings, 1 reply; 30+ messages in thread
From: Stephen Smalley @ 2005-11-16 14:26 UTC (permalink / raw)
To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
On Wed, 2005-11-16 at 09:27 -0500, Ivan Gyurdiev wrote:
> Well, okay... I guess it's about as easy to add an arbitrary prefix than
> to use the current defrole functions.
> It's probably easier, actually...
>
> So, should this go into a separate file? If it's key-ed on the user, why
> shouldn't it go into the user file?
> Also, there's the issue of local vs policy. In-policy users that are not
> in the local file also require a labeling prefix.
For local users, it could go into the users.local file managed by
libsemanage. For in-policy users, the policy package needs to provide a
new file that assigns them a labeling prefix for use by libsemanage.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 14:14 ` Stephen Smalley
@ 2005-11-16 14:27 ` Ivan Gyurdiev
2005-11-16 14:26 ` Stephen Smalley
0 siblings, 1 reply; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-16 14:27 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
>
>
> Even in semanage, defrole is potentially misleading, as the actual
> default role is context-dependent, e.g. root can be set up to login as
> staff_r by default for ssh logins (so that acquiring sysadm_r access
> requires a further step via newrole or su) while logging in as sysadm_r
> by default for console logins.
>
Well, okay... I guess it's about as easy to add an arbitrary prefix than
to use the current defrole functions.
It's probably easier, actually...
So, should this go into a separate file? If it's key-ed on the user, why
shouldn't it go into the user file?
Also, there's the issue of local vs policy. In-policy users that are not
in the local file also require a labeling prefix.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 14:26 ` Stephen Smalley
@ 2005-11-16 14:47 ` Ivan Gyurdiev
2005-11-16 14:53 ` Ivan Gyurdiev
0 siblings, 1 reply; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-16 14:47 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Daniel J Walsh, SELinux-dev, Joshua Brindle, SE Linux
Stephen Smalley wrote:
> On Wed, 2005-11-16 at 09:27 -0500, Ivan Gyurdiev wrote:
>
>> Well, okay... I guess it's about as easy to add an arbitrary prefix than
>> to use the current defrole functions.
>> It's probably easier, actually...
>>
>> So, should this go into a separate file? If it's key-ed on the user, why
>> shouldn't it go into the user file?
>> Also, there's the issue of local vs policy. In-policy users that are not
>> in the local file also require a labeling prefix.
>>
>
> For local users, it could go into the users.local file managed by
> libsemanage. For in-policy users, the policy package needs to provide a
> new file that assigns them a labeling prefix for use by libsemanage.
>
Too complicated...fewer files is better. It seems better to call a
utility in the %post script that will do if (!exists_local(root))
add_local(root, (root's data)). That also allows users to see that data
if they choose to modify the file by hand.
.. unfortunately now I'll have to modify in-policy queries in semanage
to also query the local file, and fetch the prefix from there.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: rawhide targeted vs. refpolicy rpm
2005-11-16 14:47 ` Ivan Gyurdiev
@ 2005-11-16 14:53 ` Ivan Gyurdiev
0 siblings, 0 replies; 30+ messages in thread
From: Ivan Gyurdiev @ 2005-11-16 14:53 UTC (permalink / raw)
To: Ivan Gyurdiev
Cc: Stephen Smalley, Daniel J Walsh, SELinux-dev, Joshua Brindle,
SE Linux
>>> Well, okay... I guess it's about as easy to add an arbitrary prefix
>>> than to use the current defrole functions.
>>> It's probably easier, actually...
>>>
>>> So, should this go into a separate file? If it's key-ed on the user,
>>> why shouldn't it go into the user file?
>>> Also, there's the issue of local vs policy. In-policy users that are
>>> not in the local file also require a labeling prefix.
>>>
>>
>> For local users, it could go into the users.local file managed by
>> libsemanage. For in-policy users, the policy package needs to provide a
>> new file that assigns them a labeling prefix for use by libsemanage.
>>
> Too complicated...fewer files is better. It seems better to call a
> utility in the %post script that will do if (!exists_local(root))
> add_local(root, (root's data)). That also allows users to see that
> data if they choose to modify the file by hand.
Actually, no this is a very stupid idea, because:
1) it implies prefixes for users only found in policy are local
modifications, and
2) updates will not override previous value, because they'll think it
was locally modified.
... another file is the right way to do this.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2005-11-16 14:53 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <BF9A263D.7FFA%csellers@tresys.com>
[not found] ` <4374BDEC.4050600@redhat.com>
[not found] ` <200511111717.16542.csellers@tresys.com>
[not found] ` <200511141041.49643.csellers@tresys.com>
[not found] ` <1131983537.5415.137.camel@moss-spartans.epoch.ncsc.mil>
2005-11-14 16:17 ` rawhide targeted vs. refpolicy rpm Daniel J Walsh
2005-11-14 16:51 ` Stephen Smalley
2005-11-14 18:23 ` Daniel J Walsh
2005-11-14 19:32 ` Stephen Smalley
2005-11-15 13:23 ` Stephen Smalley
2005-11-14 16:59 ` Joshua Brindle
2005-11-14 18:27 ` Daniel J Walsh
2005-11-14 19:37 ` Stephen Smalley
2005-11-15 11:17 ` Stephen Smalley
2005-11-15 13:40 ` Stephen Smalley
2005-11-15 14:44 ` Daniel J Walsh
2005-11-15 14:57 ` Stephen Smalley
2005-11-15 15:10 ` Stephen Smalley
2005-11-15 15:18 ` Stephen Smalley
2005-11-15 19:03 ` Stephen Smalley
2005-11-15 19:28 ` Joshua Brindle
2005-11-16 13:12 ` Stephen Smalley
2005-11-15 19:50 ` Ivan Gyurdiev
2005-11-16 13:11 ` Stephen Smalley
2005-11-16 13:42 ` Ivan Gyurdiev
2005-11-16 13:42 ` Stephen Smalley
2005-11-16 14:08 ` Ivan Gyurdiev
2005-11-16 14:14 ` Stephen Smalley
2005-11-16 14:27 ` Ivan Gyurdiev
2005-11-16 14:26 ` Stephen Smalley
2005-11-16 14:47 ` Ivan Gyurdiev
2005-11-16 14:53 ` Ivan Gyurdiev
2005-11-14 17:28 ` Ivan Gyurdiev
2005-11-14 18:09 ` I have modified Joshua's libsemanage-swigify patch to work better in my spec file Daniel J Walsh
2005-11-15 13:21 ` Stephen Smalley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.