regarding privilege granting

regarding privilege granting

[Steve G]

Hi,

I'm not sure I really like the idea of SE Linux getting in the business of
granting permissions. I want to make sure that we have a full discussion about
all aspects of the change. Some of these items I know can be decided by policy,
but I think you will hear things like this when it goes up for wider review. I
want to state them here so that we have answers later.

1) Education. We've been telling users all along that SE Linux does not grant
permissions. It adds restrictions on top of DAC. To change that now would likely
confusion the casual user.

2) Nothing security relavent happens without root. All of the trusted databases
require uid 0 to write to them. In some cases to read. All applications that need
special permissions have been carefully arranged to start as root and drop
capabilities as they can.

3) In the few places where setuid must be used, these programs have undergone
review dozens of times for flaws. No one allows them without much review. If SE
Linux gets into the business of granting privs, then I doubt people would give
the apps the extra amount of review that they should get.

4) Setuid apps are also given special protection by the runtime linker. Without
having the equivalent ability, you are opening the door to attacks in ways that
were probably not imagined.

5) Apps could work when SE Linux is enabled and suddenly malfunction if selinux
is disabled. I could see a case where an app had a certain power and loses it
while its running (depending on what permissive means) and leaves the system in
an unsafe state.

6) What would permissive mode look like? Would any app that wants any capability
automatically get it? If you enforce old capability model then it isn't
permissive since you won't be able to collect all the permissions that an app
needs.

7) It will be hard to find for compliance auditing any applications that have
been granted special privileges.

8) Backdoors can be planted into systems with the aid of selinux policy. People
have no way of comparing what is in memory against what is on disk. Modifying
policy in memory will become an attack point since it now can grant capabilities
instead of impose restrictions. Rootkit detectors will not be able to find this
attack vector.

9) Allowing SE Linux to override DAC restrictions means that we go from 2 layers
of security to 1 layer. All analysis would have to be done from a selinux
perspective. I seriously doubt the average admin will be able to analyze the
security implications on a server given the tools available. You would need to
have commandline tools that lets an admin make some basic discoveries about
access. They will need to be able to find all apps with elevated privileges, what
capabilities does it have. Given a file, what accounts & domain can access or
alter it, given a file and domain what actions can be performed? I think this
will tremendously complicate understanding security for your machine.

10) Simple commandline tools will need to be available for people to remove the
granted capability if they disagree with it. Think about times when people chmod
a program to remove the setuid bit so that it only runs for the admin.

11) What about signal/ptrace attacks. If apps started as a user do not change
uid, the user has control over them. Some operations follow uid rules when the
kernel is deciding whether or not to allow an interaction. If SE Linux elevates
the privs, then the user may have a new way to attack a previously unassailable
target.

There are likely many unforeseen attack vectors that this opens the door to.
There would have to be new analytical tools created to allow people to understand
what they are deploying. This has to be carefully considered by a wider audience
before proceeding.

-Steve


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

--
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.

Re: regarding privilege granting

[Stephen Smalley]

On Fri, 2007-06-15 at 08:41 -0700, Steve G wrote:
> Hi,
> 
> I'm not sure I really like the idea of SE Linux getting in the business of
> granting permissions. I want to make sure that we have a full discussion about
> all aspects of the change. Some of these items I know can be decided by policy,
> but I think you will hear things like this when it goes up for wider review. I
> want to state them here so that we have answers later.

Hi Steve,

Have you read the RFC v2 patch description?  I think it addresses many
of these concerns.  But I'll go through them one-by-one below.

> 1) Education. We've been telling users all along that SE Linux does not grant
> permissions. It adds restrictions on top of DAC. To change that now would likely
> confusion the casual user.

Being able to fully manage privileges/capabilities based on Role-Based
Access Control and Type Enforcement has been a design goal from day one,
and was identified as such back in 2000.  In fact, people new to SELinux
are often surprised that we don't already provide them with a way to
give capabilities to specific programs without them running as uid 0
(even initially); they want to do that, and they have been asking to be
able to do that ever since basic capability support went into the
mainline kernel.  There are two ways of achieving that end:  the file
capabilities patch already in -mm, or enabling security modules to fully
manage the capabilities.  FreeBSD is already doing the latter.  We think
that the latter offers some advantages over the former, as explained in
the patch description, but we aren't excluding the file capabilities
support from being used either.

> 2) Nothing security relavent happens without root. All of the trusted databases
> require uid 0 to write to them. In some cases to read. All applications that need
> special permissions have been carefully arranged to start as root and drop
> capabilities as they can.

Many users don't want to have to run everything security-relevant as
root (even initially); they want to be able to assign privileges to
users based role, and they want to be able to assign privileges to
applications without requiring them to be fully privileged at startup.
The Oracle folks specifically didn't want their software to have to run
as root on Linux (discussion on lkml a long time ago).  Again, this is
not fundamentally different than file capabilities in terms of non-root
have privs.

> 3) In the few places where setuid must be used, these programs have undergone
> review dozens of times for flaws. No one allows them without much review. If SE
> Linux gets into the business of granting privs, then I doubt people would give
> the apps the extra amount of review that they should get.

Writing SELinux policy is not easier / more prone to abuse than setting
the suid bit on a binary or setting file capabilities on it.  And it has
nothing to do with the level of review (which I think you overestimate,
especially for third party and in-house apps).

> 4) Setuid apps are also given special protection by the runtime linker. Without
> having the equivalent ability, you are opening the door to attacks in ways that
> were probably not imagined.

Um, do you not know about AT_SECURE?
http://www.ussg.iu.edu/hypermail/linux/kernel/0306.2/0105.html
We've had equivalent ability for a long time now.
And file capabilities leverages it too.

> 5) Apps could work when SE Linux is enabled and suddenly malfunction if selinux
> is disabled. I could see a case where an app had a certain power and loses it
> while its running (depending on what permissive means) and leaves the system in
> an unsafe state.

Yes, the application will lose any privileges granted in this manner if
SELinux is permissive or disabled, as noted in the patch description.
Which means that in general purpose distros (like Fedora), you won't be
able to apply this approach to your core system applications anytime
soon (until/unless we get to the point where no one even asks to turn
selinux off and policy generation is as easy to do in enforcing as
permissive).  But it can be applied incrementally even in such distros,
and it can be applied wholesale to security-oriented specialized distros
and custom builds, some of which already disable the SELinux kernel
support for disabling SELinux or making it permissive because they don't
want that to be possible. 

> 6) What would permissive mode look like? Would any app that wants any capability
> automatically get it? If you enforce old capability model then it isn't
> permissive since you won't be able to collect all the permissions that an app
> needs.

I think you need to go back and read the patch description - the above
is not correct.  Permissive situation is same as disabled, and these
rules will not and don't have to be auto generated.

> 7) It will be hard to find for compliance auditing any applications that have
> been granted special privileges.

Um, no - they will be explicitly called out by the cap_override rules in
policy.  Very easy to search for in policy, much more so than scanning
the filesystem for suid binaries or file capabilities.

> 8) Backdoors can be planted into systems with the aid of selinux policy. People
> have no way of comparing what is in memory against what is on disk. Modifying
> policy in memory will become an attack point since it now can grant capabilities
> instead of impose restrictions. Rootkit detectors will not be able to find this
> attack vector.

If you can write to kernel memory, you've won, and your "rootkit
detectors" can never reliably detect anything unless they run in a
separate VM protected from the potentially broken OS.  And overwriting
the task's uid/gid/capability bitmasks is no harder than injecting bad
rules into the avtab or entries into AVC.

> 9) Allowing SE Linux to override DAC restrictions means that we go from 2 layers
> of security to 1 layer. All analysis would have to be done from a selinux
> perspective. I seriously doubt the average admin will be able to analyze the
> security implications on a server given the tools available. You would need to
> have commandline tools that lets an admin make some basic discoveries about
> access. They will need to be able to find all apps with elevated privileges, what
> capabilities does it have. Given a file, what accounts & domain can access or
> alter it, given a file and domain what actions can be performed? I think this
> will tremendously complicate understanding security for your machine.

It actually makes it possible to understand the security of your system,
unlike the suid model or even the file capability model.  Centralized
and analyzable policy.

> 10) Simple commandline tools will need to be available for people to remove the
> granted capability if they disagree with it. Think about times when people chmod
> a program to remove the setuid bit so that it only runs for the admin.

We have talked about allowing people to insert a local module that
actually deletes any matching allow rules from the base policy, not only
for this purpose but to generally allow stripping permissions.

> 11) What about signal/ptrace attacks. If apps started as a user do not change
> uid, the user has control over them. Some operations follow uid rules when the
> kernel is deciding whether or not to allow an interaction. If SE Linux elevates
> the privs, then the user may have a new way to attack a previously unassailable
> target.

All controlled (and much more comprehensively) based on SELinux security
context/domain already.  

> There are likely many unforeseen attack vectors that this opens the door to.
> There would have to be new analytical tools created to allow people to understand
> what they are deploying. This has to be carefully considered by a wider audience
> before proceeding.

-- 
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.

Re: regarding privilege granting

[Steve G]

>> 1) Education. We've been telling users all along that SE Linux does not 
>> grant permissions. It adds restrictions on top of DAC. To change that 
>> now would likely confusion the casual user.
>
>Being able to fully manage privileges/capabilities based on Role-Based
>Access Control and Type Enforcement has been a design goal from day one,
>and was identified as such back in 2000.

Even if it was a design goal, that does not help with what everyone has been
trained to understand. We've been telling people that SE Linux is safe to use
since it does not grant any permissions, it just takes away.

>  In fact, people new to SELinux are often surprised that we don't already
> provide them with a way to give capabilities to specific programs without
> them running as uid 0 (even initially);

I think they are surprised because the assume the worst and later are relieved to
find out that DAC still has first vote and they still understand their system and
can control access rights without having to learn SE Linux policy.


>> 2) Nothing security relavent happens without root. All of the trusted 
>> databases require uid 0 to write to them. In some cases to read. All 
>> applications that need special permissions have been carefully arranged to
>> start as root and drop capabilities as they can.
>
>Many users don't want to have to run everything security-relevant as
>root (even initially);

They all do. The system will not work any other way. Do you realize how many apps
do a capability check by: if (getuid() != 0)   all those apps would break in a 
new privilege granting scheme.

>Again, this is not fundamentally different than file capabilities in terms 
>of non-root have privs.

I don't care for that either. But its probably more likely to meet compliance
issues since it can probably be worked into a 'find' command to scan the system
for programs with elevated privileges.


>> 3) In the few places where setuid must be used, these programs have 
>> undergone review dozens of times for flaws. No one allows them without
>> much review. If SE Linux gets into the business of granting privs, then I
>> doubt people would give the apps the extra amount of review that they 
>> should get.
>
>Writing SELinux policy is not easier / more prone to abuse than setting
>the suid bit on a binary or setting file capabilities on it.

I think you are missing my point. Because there is no good way to find the apps
with elevated privileges, admins will not do reviews to see if those apps are
using the special powers securely. 

> And it has nothing to do with the level of review (which I think you 
> overestimate, especially for third party and in-house apps).

setuid apps get reviewed because everyone understands the danger and people can
find all of them on their system.


>> 7) It will be hard to find for compliance auditing any applications that 
>> have been granted special privileges.
>
>Um, no - they will be explicitly called out by the cap_override rules in
>policy.  Very easy to search for in policy, much more so than scanning
>the filesystem for suid binaries or file capabilities.

There are a lot of tools that do something like:

find / -type f -perm -04000

How would you script a check like this? People have to be able to spot all apps
that have elevated privileges.

-Steve


 
____________________________________________________________________________________
We won't tell. Get more on shows you hate to love 
(and love to hate): Yahoo! TV's Guilty Pleasures list.
http://tv.yahoo.com/collections/265 

--
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.

Re: regarding privilege granting

[Karl MacMillan]

On Mon, 2007-06-25 at 08:22 -0700, Steve G wrote:
> >> 1) Education. We've been telling users all along that SE Linux does not 
> >> grant permissions. It adds restrictions on top of DAC. To change that 
> >> now would likely confusion the casual user.
> >
> >Being able to fully manage privileges/capabilities based on Role-Based
> >Access Control and Type Enforcement has been a design goal from day one,
> >and was identified as such back in 2000.
> 
> Even if it was a design goal, that does not help with what everyone has been
> trained to understand. We've been telling people that SE Linux is safe to use
> since it does not grant any permissions, it just takes away.
> 

It's simple to retain this property - just don't allow anything with the
cap_override object. It isn't hard to check policy (in source or binary
form) for this object and it is even possible to write a verification
app for the module system to prevent the installation of modules that
include cap_override permissions.

> >  In fact, people new to SELinux are often surprised that we don't already
> > provide them with a way to give capabilities to specific programs without
> > them running as uid 0 (even initially);
> 
> I think they are surprised because the assume the worst and later are relieved to
> find out that DAC still has first vote and they still understand their system and
> can control access rights without having to learn SE Linux policy.
> 

I'm not so sure about this, but I don't think the core issue here is
user perception.

> 
> >> 2) Nothing security relavent happens without root. All of the trusted 
> >> databases require uid 0 to write to them. In some cases to read. All 
> >> applications that need special permissions have been carefully arranged to
> >> start as root and drop capabilities as they can.
> >
> >Many users don't want to have to run everything security-relevant as
> >root (even initially);
> 
> They all do. The system will not work any other way. Do you realize how many apps
> do a capability check by: if (getuid() != 0)   all those apps would break in a 
> new privilege granting scheme.
> 

Steve's point, however, is that this is a _bad_ thing. Any tool that
helps remove this unsafe behavior is helpful to security.

> >Again, this is not fundamentally different than file capabilities in terms 
> >of non-root have privs.
> 
> I don't care for that either. But its probably more likely to meet compliance
> issues since it can probably be worked into a 'find' command to scan the system
> for programs with elevated privileges.
> 

See below.

> 
> >> 3) In the few places where setuid must be used, these programs have 
> >> undergone review dozens of times for flaws. No one allows them without
> >> much review. If SE Linux gets into the business of granting privs, then I
> >> doubt people would give the apps the extra amount of review that they 
> >> should get.
> >
> >Writing SELinux policy is not easier / more prone to abuse than setting
> >the suid bit on a binary or setting file capabilities on it.
> 
> I think you are missing my point. Because there is no good way to find the apps
> with elevated privileges, admins will not do reviews to see if those apps are
> using the special powers securely. 
> 

Of course there is an easy way to find applications with elevated
privileges. Find the domains with cap_override permissions (perhaps
using sesearch), find the entrypoints to that domain, and then find all
executables labeled with those entrypoints.

I'm pretty surprised that you are making the argument that these method
of granting capabilities is harder to analyze. SELinux allows you to
understand exactly what domains have the capabilities in exactly which
situations. Since executable code is tightly bound to the domains
already finding executables that can run with additional capabilities it
not hard.

Karl


--
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.

Re: regarding privilege granting

[Steve G]

>I'm pretty surprised that you are making the argument that these method
>of granting capabilities is harder to analyze. SELinux allows you to
>understand exactly what domains have the capabilities in exactly which
>situations. Since executable code is tightly bound to the domains
>already finding executables that can run with additional capabilities it
>not hard.

OK, what would I type at the command line to get the list of all apps with
elevated privileges? I already showed you the 1 line in bash that finds all
programs with elevated privileges today.

Thanks,
-Steve


 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

--
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.

Re: regarding privilege granting

[Stephen Smalley]

On Mon, 2007-06-25 at 08:22 -0700, Steve G wrote:
> >> 1) Education. We've been telling users all along that SE Linux does not 
> >> grant permissions. It adds restrictions on top of DAC. To change that 
> >> now would likely confusion the casual user.
> >
> >Being able to fully manage privileges/capabilities based on Role-Based
> >Access Control and Type Enforcement has been a design goal from day one,
> >and was identified as such back in 2000.
> 
> Even if it was a design goal, that does not help with what everyone has been
> trained to understand. We've been telling people that SE Linux is safe to use
> since it does not grant any permissions, it just takes away.

The notion that a restrictive-only security mechanism is "safe to use"
is rather flawed.  Any new security mechanism has the potential to make
the system less secure, e.g.
- There may be flaws in the code (both kernel and userland) of the new
security mechanism, and that code presents a new attack surface.
- Given a more flexible and powerful security mechanism, users will
often choose to use it to replace less flexible or powerful mechanisms.
As an example, people have used selinux to supplant use of chroot in
some instances (even within Red Hat's distribution - e.g. see named(8)
NOTES).  I have not encouraged that practice, as defense-in-depth is
useful, but realistically, if people can't take advantage of newer
mechanisms in this manner, then those newer mechanisms are less valuable
to the end user and won't actually get significant usage.

The notion that an authoritative security mechanism is necessarily less
safe is also flawed.  It comes down to policy configuration, and this
extension to selinux has been designed such that no permissions are
granted authoritatively without a new allow rule on the new cap_override
class.  So it is easy to disable this feature in policy, audit for its
use, etc.  Further, as this new mechanism can replace the current use of
setuid root programs, it can actually provide greater safety and easier
analysis/auditing.

> >  In fact, people new to SELinux are often surprised that we don't already
> > provide them with a way to give capabilities to specific programs without
> > them running as uid 0 (even initially);
> 
> I think they are surprised because the assume the worst and later are relieved to
> find out that DAC still has first vote and they still understand their system and
> can control access rights without having to learn SE Linux policy.

No, we often find people disappointed and looking for other solutions to
the problem of how to grant capabilities to non-root processes when we
tell them that SELinux cannot do that by itself.  This is what drives
people to things like file capabilities, which have their own set of
issues (e.g. hardcoded capability evolution logic, distributed
protection state).  As well as to userland role-based schemes that are
in fact implemented entirely via trusted programs (sudo-like) with
inadequate kernel support to provide real protection.

> >> 2) Nothing security relavent happens without root. All of the trusted 
> >> databases require uid 0 to write to them. In some cases to read. All 
> >> applications that need special permissions have been carefully arranged to
> >> start as root and drop capabilities as they can.
> >
> >Many users don't want to have to run everything security-relevant as
> >root (even initially);
> 
> They all do. The system will not work any other way. Do you realize how many apps
> do a capability check by: if (getuid() != 0)   all those apps would break in a 
> new privilege granting scheme.

Such hardcoded checks in applications are undesirable, as is making uid
0 all powerful, just as in the kernel.  We have already extended a
number of those applications to also apply an orthogonal SELinux
permission check so that we can limit what even uid 0 processes can do
via such applications, in the same way that we modified the kernel to
apply a SELinux check whenever a capability was checked.  Further
enhancing those applications to allow similar overrides based entirely
on SELinux policy would be the next logical step after this kernel
enhancement is made.  Again, think of how you would actually want a real
role-based system to work - you want users logging in as themselves and
creating a session in a desired role, then performing operations in that
role without needing to separately switch to uid 0.

> >Again, this is not fundamentally different than file capabilities in terms 
> >of non-root have privs.
> 
> I don't care for that either. But its probably more likely to meet compliance
> issues since it can probably be worked into a 'find' command to scan the system
> for programs with elevated privileges.

So can searching for file entrypoint types for domains allowed
cap_override permissions.  It might not be a trivial command line today,
but that's because this is newly proposed kernel functionality.
Shouldn't be a difficult extension to sesearch to extract those file
entrypoint types and then feed that list to a find command.

-- 
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.

Re: regarding privilege granting

[Stephen Smalley]

On Mon, 2007-06-25 at 09:26 -0700, Steve G wrote:
> >I'm pretty surprised that you are making the argument that these method
> >of granting capabilities is harder to analyze. SELinux allows you to
> >understand exactly what domains have the capabilities in exactly which
> >situations. Since executable code is tightly bound to the domains
> >already finding executables that can run with additional capabilities it
> >not hard.
> 
> OK, what would I type at the command line to get the list of all apps with
> elevated privileges? I already showed you the 1 line in bash that finds all
> programs with elevated privileges today.

Doesn't exist today, but not hard to do as an extension to sesearch I
would think - search policy for all allow rules on cap_override class,
then find the entrypoint types for those domains, then feed that list of
types to a find command.

The fact that we don't have a one-line command line to do it today is
hardly surprising given that the kernel functionality is only just being
proposed.

-- 
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.

Re: regarding privilege granting

[Karl MacMillan]

On Mon, 2007-06-25 at 13:03 -0400, Stephen Smalley wrote:
> On Mon, 2007-06-25 at 09:26 -0700, Steve G wrote:
> > >I'm pretty surprised that you are making the argument that these method
> > >of granting capabilities is harder to analyze. SELinux allows you to
> > >understand exactly what domains have the capabilities in exactly which
> > >situations. Since executable code is tightly bound to the domains
> > >already finding executables that can run with additional capabilities it
> > >not hard.
> > 
> > OK, what would I type at the command line to get the list of all apps with
> > elevated privileges? I already showed you the 1 line in bash that finds all
> > programs with elevated privileges today.
> 
> Doesn't exist today, but not hard to do as an extension to sesearch I
> would think - search policy for all allow rules on cap_override class,
> then find the entrypoint types for those domains, then feed that list of
> types to a find command.
> 
> The fact that we don't have a one-line command line to do it today is
> hardly surprising given that the kernel functionality is only just being
> proposed.
> 

Python script for this below - most of the scripting is just converting
output from one command for input to another. Note that this just finds
entrypoints that can reach domains with cap_override. Much more thorough
and interesting analysis of how the capabilities are used can be done
reflecting the better control over capabilities that selinux provides
over the current mechanism.

This was tested using the capabilities class - I don't have a system
with the cap_override object so I would appreciate testing from someone
that does.

Karl

# Authors: Karl MacMillan <kmacmillan@mentalrootkit.com>
#
# Copyright (C) 2007  Red Hat
# see file 'COPYING' for use and warranty information
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; version 2 only
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#

import commands
import subprocess

def find_cap_domains():
    out = commands.getoutput("/usr/bin/sesearch --allow -c cap_override")
    domains = []
    for line in out.split("\n"):
        s = line.lstrip().split()
        if len(s) < 2 or s[0] != "allow":
            continue
        domains.append(s[1])
    return domains

def find_entrypoints(domains):
    entrypoints = { }
    search = "|".join(domains)
    out = commands.getoutput("/usr/bin/sesearch --allow -s '%s' -p entrypoint" % search)
    for line in out.split("\n"):
        s = line.lstrip().split()
        if len(s) < 3 or s[0] != "allow":
            continue
        entrypoints[s[2]] = ''

    return entrypoints

def find_files(domains):
    contexts = []
    for domain in domains.keys():
        contexts.append("-context '*:*:%s'" % domain)

    search = " -or ".join(contexts)
    cmd = "/usr/bin/find . \( %s \) -print0 | xargs -0 ls -Z" % search

    subprocess.call(cmd, shell=True)

def main():
    cap_domains = find_cap_domains()
    entrypoints = find_entrypoints(cap_domains)
    find_files(entrypoints)

main()



--
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.

Re: regarding privilege granting

[Steve G]

>> The fact that we don't have a one-line command line to do it today is
>> hardly surprising given that the kernel functionality is only just being
>> proposed.
> 
>
>Python script for this below - most of the scripting is just converting
>output from one command for input to another.

Karl, 

Thanks for making a tool. Of course I can't check it, but hopefully this (or
something like it) gets picked up by some package because people will have to do
this kind of search/scan as required by some compliance regulations.

-Steve


      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

--
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.

file_contexts & labelling...

[Hasan Rezaul-CHR010]

Hi All,

Suppose I use the Fedora Core 6 *strict* policy as my base...

I get the following file_context files as part of it:

/etc/selinux/strict/modules/active/file_contexts
/etc/selinux/strict/modules/active/file_contexts.template
/etc/selinux/strict/contexts/files/file_contexts

Lets say on my Linux machine I have a few additional directories under /
e.g.  /data , /download

And I want to label these directories a particular way... e.g.   I want
to label /data  as var_t for example...

I modified the above three file_context files to achieve this, such that

When I do "restorecon -rF /data" , the /data directory gets labeled as
var_t .

The problem I have is that:

Any time I execute commands (e.g. semanage or semodule) to modify the
running selinux policy, ...  the above three files automatically revert
back to their original version, and the changes I made to them get lost
!

How can I create modified file_context files or any other appropriate
file(s), such that, my changes are retained and stay permanent... So
that anytime I later need to relabel my /data directory, the directory
gets labeled the way I want, and doesn't get assigned default_t  or
file_t  or unlabeled_t, etc.

Question #2
------------

If I have setup my Linux <-> SELinux login mappings such that a regular
Linux user ssh into the box and gets context  user:user_u:user_t    and
it generally works... 
But sometimes something in my policy is getting corrupted ?!? such that
the login mappings remain exactly the same as before, but for some
strange reason, that regular Linux user ssh into the Linux box, but gets
context
system_u:system_r:kernel_t

Where should I look to see whats breaking to cause this anomaly ?


Thanks as always for your great help  :-)

- Reza.
 


--
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.

Re: file_contexts & labelling...

[Joshua Brindle]

Hasan Rezaul-CHR010 wrote:
> Hi All,
>
> Suppose I use the Fedora Core 6 *strict* policy as my base...
>
> I get the following file_context files as part of it:
>
> /etc/selinux/strict/modules/active/file_contexts
> /etc/selinux/strict/modules/active/file_contexts.template
> /etc/selinux/strict/contexts/files/file_contexts
>
>   

you should never modify files in the modules directory, these are a 
private resource of libsemanage and are subject to change/go away/etc. 
the contexts/files/file_contexts file is regenerated when any 
semanage/semodule command is run. You need to use semanage fcontext to 
add new file contexts to the system (or put them in a modules 
file_context section)

> Lets say on my Linux machine I have a few additional directories under /
> e.g.  /data , /download
>
> And I want to label these directories a particular way... e.g.   I want
> to label /data  as var_t for example...
>
> I modified the above three file_context files to achieve this, such that
>
> When I do "restorecon -rF /data" , the /data directory gets labeled as
> var_t .
>
> The problem I have is that:
>
> Any time I execute commands (e.g. semanage or semodule) to modify the
> running selinux policy, ...  the above three files automatically revert
> back to their original version, and the changes I made to them get lost
> !
>
> How can I create modified file_context files or any other appropriate
> file(s), such that, my changes are retained and stay permanent... So
> that anytime I later need to relabel my /data directory, the directory
> gets labeled the way I want, and doesn't get assigned default_t  or
> file_t  or unlabeled_t, etc.
>
> Question #2
> ------------
>
> If I have setup my Linux <-> SELinux login mappings such that a regular
> Linux user ssh into the box and gets context  user:user_u:user_t    and
> it generally works... 
> But sometimes something in my policy is getting corrupted ?!? such that
> the login mappings remain exactly the same as before, but for some
> strange reason, that regular Linux user ssh into the Linux box, but gets
> context
> system_u:system_r:kernel_t
>
>   

need more info, what does the seusers file look like after this happens, 
what seems to trigger it, etc.

> Where should I look to see whats breaking to cause this anomaly ?
>
>
> Thanks as always for your great help  :-)
>
> - Reza.
>  
>
>
> --
> 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.
>
>   



--
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.