|
|
| Line 5: |
Line 5: |
| * Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>) | | * Is SELinux enabled by default on Debian? If not, link to appropriate information (<http://wiki.debian.org/SELinux>) |
| * Is <code>system_u:object_r:httpd_sys_content_t</code> required for all SugarCRM files? | | * Is <code>system_u:object_r:httpd_sys_content_t</code> required for all SugarCRM files? |
|
| |
| <pre>
| |
| (07:46:36 AM) domg472: chcon is not good
| |
| (07:46:51 AM) domg472: if you have access to semanage use semanage
| |
| (07:47:00 AM) domg472: it is persistent
| |
| (07:47:17 AM) domg472: after relabel it will be still there
| |
| (07:47:26 AM) domg472: unlike chcons
| |
| (07:47:37 AM) domg472: chcon is for unprivileged users
| |
| </pre>
| |
|
| |
| Wiki feedback from domg472:
| |
| <pre>
| |
| Explain newrole versus sudo to: transition user domain.
| |
|
| |
| in f10 selinux-policy-targeted newrole is no longer encouraged to be used for domain transitions.
| |
| in policy mls it is still used (but mls is not common)
| |
|
| |
| sudo allows root privileges without actually knowing the root password.
| |
|
| |
| su with newrole still requires a user to enter a root password to gain root privileges.
| |
|
| |
| not needing a root password anymore is a big advantage!
| |
|
| |
| ---
| |
|
| |
| from the wiki:
| |
| SELinux and virtualization (relabeling images if images are not in /etc/xen/).
| |
|
| |
| this is not a domain specific issue. customized types. the solution should be man virt_selinux
| |
| or man xen_selinux like man httpd_selinux. however there is no man xen_selinux yet etc.
| |
| this may no longer be an issue in fedora 10 , virt is working on a solution to be implemented in f10
| |
|
| |
| ---
| |
|
| |
| make sure to use proper selinux terminology consequent in an effort to keep it simple.
| |
|
| |
| subject object, security context, domain types, file types, port types, security level, categories,
| |
| domain transition, executable file types, domain, application domain, user domain, init daemon,
| |
| classes, attributes, scontext, tcontext, access vector cache, type enforcement, multi level security,
| |
| multi category security.
| |
|
| |
| ---
| |
|
| |
| from the wiki:
| |
| Mounting:
| |
|
| |
| • Do mount points need to be mnt_t?
| |
|
| |
| boolean mount_any_file. this is also kind of a customized type issue.
| |
| use semanage boolean -l to list all booleans and their explanation. for example:
| |
|
| |
| /usr/sbin/semanage boolean -l | grep mount
| |
|
| |
| sh-3.2# /usr/sbin/semanage boolean -l | grep mount
| |
| allow_mount_anyfile -> off Allow the mount command to mount
| |
| any directory or file.
| |
| xguest_mount_media -> off Allow xguest users to mount removable media
| |
|
| |
| consideration: you should consider to not mention get,setsebool.
| |
| semanage also provides this functionality. keep it simple
| |
|
| |
| ---
| |
|
| |
| from the wiki:
| |
| mislabeled files, relabeled but still problems, touch /.autorelabel (Dans journal).
| |
| aplain how touch /.autorelabel && reboot relates to fixfiles relabel
| |
|
| |
| ---
| |
|
| |
| different policies:
| |
| first there was strict and optional mls (for dod). strict was in fedora2. it was
| |
| introduced too soon. users were too restricted. targeted was introduced to avoid
| |
| restriction on users.unconfined domain is a domain exempted fro m most selinux policy.
| |
| unconfined is a property of targeted policy. targeted policy only targets a select group.
| |
| strict targets everything on a system. targeted plus multi category security (mcs) which
| |
| is a (poor) implementation of confidentiality(its discretionary users can chcat aslong
| |
| as they are member of the cat. mcs in policy mls is part of security level. in policy
| |
| mls, mcs is mandatory.mls is strict plus BLP, plus MCS, plus MLS. strict no longer
| |
| maintained, merged with targeted. (strict plus unconfined domain) if you remove the
| |
| unconfined domain then you use what use to be strict. at the moment there are two
| |
| selinux policy models maintained: policy targeted and policy-mls. mls aims to enforces confidentiality BLP.
| |
| </pre>
| |
|
| |
| Suggestions from domg472:
| |
| <pre>
| |
| Basic access control models ( DAC , MAC ) ( not so basic MDAC )
| |
|
| |
| explain discretionary
| |
|
| |
| explain the dac model attributes: user group permission bits
| |
|
| |
| explain why dac acl is not sufficient. example privilege escalation
| |
|
| |
| explain the mac model attributes: security context
| |
|
| |
| explain mandatory
| |
|
| |
| explain that MAC is ACL layer on top of the DAC ACL layer
| |
|
| |
| explain Type enforcement
| |
|
| |
| explain Role Based AC
| |
|
| |
| explain Multi Level Security
| |
|
| |
| Explain Multi Category/Compartment Security
| |
|
| |
|
| |
|
| |
| compare a selinux system to a submarine with compartments. if one compartment has a leak,
| |
| the water will be contained to that compartment and will not be able to spread ( escalate) . submarine will not sink
| |
|
| |
|
| |
|
| |
| Security context / SELinux attributes
| |
|
| |
|
| |
|
| |
| explain the security context tuple and how to read it (explain the fields)
| |
|
| |
| explain user ( which SELinux user (group) created the object? )
| |
|
| |
| explain type is the attribute for type enforcement (TE)
| |
|
| |
| explain role is the attribute for role enforcement (RBAC)
| |
|
| |
| explain security level is the attribute for security level enforcement (MLS)
| |
|
| |
| explain categories/compartments is the attribute for security level enforcement or category/compartment enforcement (MLS or MCS)
| |
|
| |
|
| |
|
| |
| Subjects and objects ( processes and "files" )
| |
|
| |
|
| |
|
| |
| explain that everything in a system is a object
| |
|
| |
| explain that even subjects in a system are represented as objects in proc mountpoint
| |
|
| |
| explain subjects and objects
| |
|
| |
| explain subjects are processes (ps auxZ)
| |
|
| |
| explain objects are "files" (ls -alZ)
| |
|
| |
| - file objects ( files , lnk files, dirs, fifo files, sock files etc)
| |
|
| |
| - port objects
| |
|
| |
| - interface objects
| |
|
| |
| - node objects
| |
|
| |
| - objects available by other programs ACE access control extension: XACE, sepostgesql, SEDBUS, mscd, etc.
| |
|
| |
| - explain object is a class defined in kernel :process :file :tcp_socket
| |
|
| |
| example of a class: process. example of a class: file
| |
|
| |
| explain domain type is the attribute of a process ( user_t is (user) domain type/attribute of "user"
| |
|
| |
| explain object type is the attribute of a object or "file". do not mistake files with file objects/file types. a "file" is
| |
| any object
| |
|
| |
| explain that a object type can never be a scontext ( source context ) in a avc denail
| |
|
| |
| explain that processes (subjects) generally operate on files (objects)
| |
|
| |
| explain that processes (subjects) also operate on other processes (subjects) example: process ( sigchld ) if a user
| |
| processes spawns a program process.
| |
|
| |
| explain that "files" ( objects ) do not operate. they get operated on by subjects ( processes )
| |
|
| |
| explain permissions that define how to operate on subjects and objects ( classes ) are defined in the kernel and are attributes of classes
| |
|
| |
| explain classes and their attributes are static defined in kernel:
| |
|
| |
| - example of a file object class and its attributes:
| |
|
| |
| + file read
| |
|
| |
| + dir write
| |
|
| |
| + lnk_file getattr
| |
|
| |
| - example of a subject class and its attributes:
| |
|
| |
| + process sigchld
| |
|
| |
| - example of a object available by other programs ACL
| |
|
| |
| + dbus send_msg
| |
|
| |
| explain that although classes and their attributes are defined in the kernel, that one can assign "types" to
| |
| subjects and objects, and that one can define policy for these types can interact using the object classes
| |
| and their attributes supplied by the kernel.
| |
|
| |
|
| |
|
| |
| example:
| |
|
| |
|
| |
|
| |
| scontext/domain type/subject | tcontext/file type/object | "object" class | "object" permissions/attributes
| |
|
| |
| ___________________________________________________________________________________________________________________________
| |
|
| |
| user_t | user_home_t | dir | getattr
| |
|
| |
| httpd_t | httpd_sys_content_ra_t | file | read
| |
|
| |
| user_t | mozilla_t | process | sigchld
| |
|
| |
| user_t | self | process | transition
| |
|
| |
| mozilla_t | httpd_port_t | tcp_socket | connect
| |
|
| |
| unconfined_t | cupsd_t | dbus | send_msg
| |
|
| |
|
| |
|
| |
|
| |
|
| |
| How to find out if selinux is supported /enabled:
| |
|
| |
| supported?: http://domg444.blogspot.com/2007/11/how-to-determine-if-our-system-supports.html
| |
|
| |
| enabled?: getenforce /selinux/config sestatus
| |
|
| |
|
| |
|
| |
| explain selinux framework and selinux policy. explain the selinux framework is responsible for enforcing policy.
| |
|
| |
| explain the access vector cache.
| |
|
| |
| perruse selinux packages ( rpm -ql ) and discuss important locations : /etc/selinux , /selinux
| |
|
| |
|
| |
|
| |
| How to disable SELinux: i refer to dwalsh blog. some highlights selinux=0 , enforcing=0, setenforce 0,
| |
| system-config-selinux, semanage
| |
|
| |
|
| |
|
| |
| system-config-selinux is a GUI for semanage. semanage is THE central managing point for SELinux administration:
| |
|
| |
| label file objects ( semanage fcontect -a)
| |
|
| |
| label port objects ( semanage port -a) etc
| |
|
| |
| explain each optipn of semanage and system-config-selinux: label interfaces, set booleans, add , modify, delete selinux user (groups) and SELinux logins.
| |
|
| |
| explain translation ( requires mcstransd )
| |
|
| |
| explain what mcstransd does
| |
|
| |
| explain what restorecond does
| |
|
| |
| explain auditd connection to selinux ( explain ausearch /auctl )
| |
|
| |
|
| |
|
| |
| show some pratical examples for managing users. add a unconfined user , add a confined user ,
| |
| add a staff users, assign mcs categories to user (ranges)
| |
|
| |
| create custom selinux user groups
| |
|
| |
| create custom selinux logins
| |
|
| |
|
| |
|
| |
| explain booleans
| |
|
| |
| explain customizable types
| |
|
| |
| mention manual pages for targeted daemons.
| |
|
| |
|
| |
|
| |
| explain audit2allow
| |
|
| |
| explain audit2why
| |
|
| |
| explain sesearch and how you can use this to make decisions
| |
|
| |
| explain semodule, sestatus , restorecon , semanage, setenforce , getenforce
| |
|
| |
| explain limitations of chcon
| |
|
| |
| explain advantage of chcon
| |
|
| |
| explain chcat
| |
|
| |
|
| |
|
| |
| explain selinux-policy-devel ( /usr/share/selinux/devel/Makefile )
| |
|
| |
| show example how to make a custom policy module
| |
|
| |
| explain the limitations of a policy module package
| |
|
| |
| explain the advantages of a policy module package
| |
|
| |
|
| |
|
| |
| explain role base access control and derrived types.
| |
|
| |
|
| |
|
| |
| explain star and selinux tar support (exmaples)
| |
|
| |
|
| |
|
| |
| important: Possible problems caused from running in permissive mode, such as having permissions to mislabel files.
| |
|
| |
| important: Copying Vs moving files.
| |
|
| |
|
| |
|
| |
| explain avc denials field by field.
| |
|
| |
| explain advantage and limitation of sealert/setroublehoot and how this relates to audit.
| |
|
| |
|
| |
|
| |
| explain file_t, unlabeled_t
| |
|
| |
| explain initrc_t
| |
|
| |
| explain unconfined_t
| |
|
| |
| explain sepolgen and gui
| |
|
| |
|
| |
|
| |
| explain why /tmp will not be relabled: http://domg444.blogspot.com/2007/11/why-files-with-incompatible-types-in.html
| |
|
| |
|
| |
|
| |
| read selinux by example book
| |
|
| |
|
| |
|
| |
| explain the MLS vs TARGETED
| |
|
| |
| explain mcs role in targetted versus mcs role in mls
| |
| </pre>
| |
|
| |
| dependencies and selinux-policy by domg472:
| |
| <pre>
| |
| SELinux policy and dependencies.
| |
|
| |
| A policy module has 3 files. Here is the explaination of the 3 files.
| |
|
| |
| mydomain.te (.te) (type enforcement file) it has PRIVATE policy for the "mydomain" policy module.
| |
|
| |
| mydomain.if (.if) (interface file) it has PUBLIC policy for the "mydomain" policy module.
| |
|
| |
| mydomain.fc (.fc) (file context file) it has file contexts for the "mydomain" policy module.
| |
|
| |
| The type enforcement file.
| |
|
| |
| This file has private policy. Policy that is, in my example, related to "mydomain"
| |
|
| |
| for example, you might find a rule like this in the mydomain.te file:
| |
| apache_read_user_content(mydomain_t)
| |
|
| |
| This policy was provided by apache.if to "mydomain". You can look it up in the apache.if file.
| |
| It is really a template or interface with rules for how to read apaches user content.
| |
| We are using (instantiating) that interface that apache policy module provides in it's
| |
| apache.if file, in our mydomain.te file.
| |
|
| |
| Let us refer to interfaces and templates as blocks of public policy. Public policy blocks
| |
| should be prefixed by the policy module name of the domain that facilitates it in it's .if (interface file).
| |
|
| |
| for example, just by looking at the following interface call in mydomain.te i know:
| |
| 1. which module provided the interface 2. where to roughly find it. 3. where to find what
| |
| policy te interface provides. 4. which domain instantiates the block of public policy:
| |
|
| |
| alsa_read_rw_config(mydomain_t)
| |
|
| |
| 1. provided by the alsa policy module.
| |
| 2. can be found in alsa.if
| |
| 3. Summary: Read alsa writable config files
| |
|
| |
| allow $1 alsa_etc_rw_t:dir list_dir_perms;
| |
| read_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
| |
| read_lnk_files_pattern($1,alsa_etc_rw_t,alsa_etc_rw_t)
| |
|
| |
| 4. this policy is instantiated by mydomain_t domain.
| |
|
| |
| So you can easily from looking at a .te file know the modules dependencies by
| |
| parsing each called interface prefix. as each called interface is prefixed by the domain
| |
| that made it available in its interface file.
| |
|
| |
| important note regarding public policy.
| |
|
| |
| creating a quick policy module package(.pp) can be very handy for implementing
| |
| quick policy. but it is also limited.
| |
|
| |
| to compile policy one need selinux-devel. it has development files for each module that
| |
| is used by the compiler to see if the policy that we want to compile is valid.
| |
|
| |
| when you compile and install a seperate policy package with semodule -i mydomain.pp for example.
| |
| there will not be a devel package installed.
| |
|
| |
| interfaces files are therefore rendered useless for seperate policy module packages. for the
| |
| reason that other modules will not be able too instantiate any public policy for that module.
| |
|
| |
| the reason is that when you try to compile your module that has a call to a public policy block
| |
| of a module that was installed with semodule, the compiler will nnot find that interface/ template
| |
| in its devel files because non were installed!
| |
|
| |
| This is important to know!
| |
| do you want to develop and implement much policy, then do not use policy module packages with
| |
| semodule but instead integrate your module into the selinux-policy source provided upstream,
| |
| rebuild it and reinstall it.
| |
|
| |
| by rebuilding selinux-policy, a new selinux-policy-devel package is created. this selinux-policy-devel
| |
| package DOES include the public policy for the domain that you integrated and thus is usable as
| |
| opposed to using a .pp with semodule.
| |
|
| |
| <http://domg472.blogspot.com/2008/05/how-to-create-integrate-and-rebuild.html>
| |
| </pre>
| |
|
| |
| From Max:
| |
| <pre>
| |
| Murray McAllister wrote:
| |
|
| |
| >
| |
| > There are a few SELinux books, but these are very technical. We want to create a guide
| |
| >that people with no previous SELinux experience can use, to allow them to do what they
| |
| >want without turning SELinux off.
| |
| >
| |
|
| |
| >
| |
| > If anyone has any ideas about what they would like to see in the guide, or
| |
| >any corrections to the current topics we would like to include, please let us know.
| |
| >As well, user feedback and comments can be left at
| |
| ><https://fedoraproject.org/wiki/Docs/Drafts/SELinux_User_Guide/SELinux_Feedback>.
| |
| A Fedora account >(https://admin.fedoraproject.org/accounts/) is required to use the Wiki -
| |
| >if you do not have one, please do not hesitate to mail me directly, or respond to this thread.
| |
| >
| |
|
| |
| Here are a few ideas with comments in no particular order:
| |
|
| |
| 0 - *Reference material* - Not something many will probably dive into but necessary for completeness.
| |
| Just some links to other sources of info. Like the IBM page :
| |
|
| |
| > http://www.ibm.com/developerworks/linux/library/l-selinux/?ca=dgr-lnxw01SELinux
| |
|
| |
| Even if there is no link directly to this page a small *Further Info* section like the Resources
| |
| section at the bottom would still be useful, links to papers and web pages that can explain
| |
| things in more detail if anyone is interested in finding out more of the nuts and bolts stuff.
| |
|
| |
| Also perhaps links to any threads in the mailing list archives that help explain some of the concepts,
| |
| these might be sprinkled about so they end up in relevant places. So if the section is about TE rules
| |
| and there is a thread in the archives that was particularly good at explaining this or covers some key
| |
| points then drop a link to the relevant thread there as additional reference or draw useful examples
| |
| from the archives to use in explaining things. Showing how a real world problem was solved step by
| |
| step has more impact than using myapp_t.
| |
|
| |
| 1 - *What SELinux isn't* - not an antivirus, will not fix vulnerabilities, etc ....Maybe slip
| |
| in a few lines explaining the concept of default permit and why this is a bad idea. *No such
| |
| thing as a free lunch*. Which leads to the concept of default deny and....
| |
|
| |
| 2 - *What is SELinux and why should I care* - MAC system uses type enforcement to confine
| |
| applications.....default deny. Everything that is to be allowed must be expressed in policy.
| |
| Policy is complex because the system is complex. Typical usage of SELinux, the apache example
| |
| would fit well in this section. What the goal of refpolicy is, where it is , where its going.
| |
| Its not called reference policy for nothing, use as a building block.
| |
|
| |
| 3 - *Explain unconfined*. For instance going through the archives I found this little tidbit :
| |
|
| |
|
| |
| > Allowing unconfined_t to do things is ok; it is supposed to be unrestricted
| |
| (and usually this happens automatically when you use the right type attributes
| |
| on any new types you define, like the "file_type" attribute for file types and the
| |
| "domain" attribute for domains). Allowing other domains to access unconfined_t is the concern.
| |
|
| |
| > http://www.nsa.gov/seLinux/list-archive/0610/17941.cfm
| |
|
| |
| Above is the link to the message in the archives that I pulled the quote from, in case
| |
| anyone is wondering about the context this was said in, though the statement by my
| |
| estimation is straight forward and not context dependent in this case.
| |
|
| |
| Some explanation of unconfined should be given and points like not letting other domains
| |
| access unconfined should be made crystal clear, is it ever acceptable?If so under what conditions.
| |
|
| |
| 4 - *Admin Skills*
| |
|
| |
| From recent traffic to fedora-selinux :
| |
|
| |
| > I guess this is the number one thing we need to teach unix
| |
| > administrators. With SELinux when you get a permission denied message
| |
| > there are 3 things to check. Ownership, Permissions which all admins
| |
| > have ingrained into them, and SELinux Label.
| |
| >
| |
| > chown OWNER PATH
| |
| > chmod PERM PATH
| |
| > restorecon PATH
| |
|
| |
| This brings us to the Z option , very useful, often forgotten(maybe it should be automatic
| |
| with commands like ls -l). Also a complete listing of SELinux commands. Refer people to man
| |
| pages except where command may be commonly used by admins.
| |
|
| |
| Listing of most commonly encountered issues with explanations and typical fixes. The most
| |
| important thing is explaining how to determine what the problem is and the general diagnostic
| |
| approach one should use.
| |
|
| |
| How do I tell the difference between the common and uncommon issues? Is there a general way to
| |
| determine this? Somethings are never easy to explain but clues as to what should be looked for are invaluable.
| |
|
| |
| Listing of not so common problems and a general diagnostic approach to take for these issues.
| |
|
| |
| At least a minimal list of info that you should include when asking for help on the mailing list.
| |
| Who, what, when, where, why stuff that is useful in diagnosing problems. Like the top 5 things
| |
| the SELinux guru would like to know or needs to know to help resolve the issue.
| |
|
| |
|
| |
|
| |
| 5 - *audit2why and audit2allow* - The man pages explain pretty well what to do and how to do it.
| |
| I would definitely include an explanation of these because they can be the primary tool for solving
| |
| denials but if your going to copy and paste the man page then I would say don't bother. So I like
| |
| the man page but if you can't take a slightly different approach to explaining it then I don't see
| |
| the point of reiterating what's available from man audit2allow. Maybe just changing the order of
| |
| the info presented would be enough, so its a little less tech manual and a little more conversational,
| |
| more wiki less man page. This is the overall goal anyway.
| |
|
| |
| From the man page:
| |
|
| |
| > Care must be exercised while acting on the output of this utility to
| |
| > ensure that the operations being permitted do not pose a security
| |
| > threat. Often it is better to define new domains and/or types, or make
| |
| > other structural changes to narrowly allow an optimal set of operations
| |
| > to succeed, as opposed to blindly implementing the sometimes broad
| |
| > changes recommended by this utility.
| |
|
| |
| This seems to me to be the most important point when using audit2allow. Here as a segue into
| |
| writing policy there should be some of the *do nots of policy writing*, so if audit2allow happens
| |
| to suggest one of these it either definitely shouldn't be allowed or requiring permissions of this
| |
| kind should be considered an application bug or policy bug , bounce it off your distros selinux list etc...
| |
|
| |
|
| |
| > Certain permission denials are
| |
| > not fatal to the application, in which case it may be preferable to
| |
| > simply suppress logging of the denial via a ’dontaudit’ rule rather
| |
| > than an ’allow’ rule.
| |
|
| |
| Breakdown the different rules, at least one of each, explain the conventions of policy language.
| |
| How deep into policy langauge this needs to go I am not sure but most of what prompts people to
| |
| turn SELinux off or ignore it is lack of understanding. Nothing turns people off like being
| |
| confused but being in the dark is worse, too much info is better than not enough IMO. For
| |
| instance the reserved word self , the wildcard and complement operators, all useful to know
| |
| about and very dangerous if you stumble across it and don't fully understand the implications of
| |
| using or not using it.
| |
|
| |
| 6 - *Explanation of the major concepts*. Types, domains, context, object classes etc....
| |
|
| |
| 7 - *Thorough breakdown of AVC*. This is really important. It is essentially the face of SELinux.
| |
| If all goes well you'll never know its there but if something breaks then this is likely to make
| |
| me want to take a header off the nearest skyscraper :
| |
|
| |
| time->Tue Jul 15 22:02:04 2008
| |
| type=SYSCALL msg=audit(1216173724.561:64): arch=c000003e syscall=6 success=no exit=-13
| |
| a0=1bcdaa5 a1=7fff450fea80 a2=7fff450fea80 a3=7faa3d0e4810 items=0 ppid=9135 pid=9143
| |
| auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts2
| |
| ses=2 comm="passwd" exe="/usr/bin/passwd" subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 key=(null)
| |
| type=AVC msg=audit(1216173724.561:64): avc: denied { search } for pid=9143 comm="passwd"
| |
| name="tmp" dev=dm-0 ino=12 scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023
| |
| tcontext=system_u:object_r:tmp_t:s0 tclass=dir
| |
|
| |
| Now experienced admins can figure out most of it or google for answers but this is for
| |
| the inexperienced, running a desktop system, exactly where this is needed most, they may
| |
| not have basic admin skills or care about learning them, so a comprehensive breakdown of
| |
| the AVC is essential. I should be able to bookmark this page and use it for reference.
| |
|
| |
| 8 - *ausearch* is another must have in the arsenal of the admin. Alot of options here.
| |
| Just a small random selection of them :
| |
|
| |
| -c, --comm comm-name
| |
| Search for an event based on the given comm name. The comm name is the executable’s
| |
| name from the task structure.
| |
|
| |
| -hn, --host host-name
| |
| Search for an event with the given host name. The hostname can be either a hostname,
| |
| fully qualified domain name, or numeric network address. No attempt is made to
| |
| resolve numeric addresses to domain names or aliases.
| |
|
| |
| -if, --input file-name
| |
| Use the given file instead if the logs. This is to aid analysis where the logs
| |
| have been moved to another machine or only part of a log was saved.
| |
|
| |
| --input-logs
| |
| Use the log file location from auditd.conf as input for searching. This is needed
| |
| if you are using ausearch from a cron job.
| |
|
| |
|
| |
| *Lots of ways to search. Can be used in conjunction with audit2allow:*
| |
|
| |
| [root@localhost ~]# ausearch -m avc | audit2allow
| |
|
| |
|
| |
| #============= NetworkManager_t ==============
| |
| allow NetworkManager_t fixed_disk_device_t:blk_file getattr;
| |
|
| |
| #============= avahi_t ==============
| |
| allow avahi_t user_home_t:file write;
| |
|
| |
| #============= consoletype_t ==============
| |
| allow consoletype_t dhcpc_state_t:file read;
| |
|
| |
|
| |
| 9 - *Examples,Examples,Examples*
| |
|
| |
| What did I search by?How can this be useful to me? Its all in the man pages of
| |
| course but man pages are dry and the output is intimidating.
| |
|
| |
| [root@localhost ~]# ausearch -a 30 | grep SYSCALL
| |
| type=SYSCALL msg=audit(1212681693.050:30): arch=c000003e syscall=59 success=yes exit=0
| |
| a0=403665 a1=7fff4a0fbba0 a2=7fff4a0fc228 a3=0 items=0 ppid=5712 pid=5713 auid=4294967295
| |
| uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="umount" exe="/bin/umount" subj=system_u:system_r:mount_t:s0 key=(null)
| |
| type=SYSCALL msg=audit(1213111393.121:30): arch=c000003e syscall=2 success=no exit=-13
| |
| a0=7fff0a76d7d0 a1=2 a2=14 a3=0 items=0 ppid=4308 pid=4309 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
| |
| egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lsusb" exe="/sbin/lsusb" subj=system_u:system_r:cupsd_config_t:s0
| |
| key=(null) type=SYSCALL msg=audit(1214321269.400:30): arch=c000003e syscall=59 success=yes exit=0
| |
| a0=14ebba0 a1=14a53c0 a2=14a8b20 a3=8 items=0 ppid=4104 pid=4114 auid=500 uid=0 gid=0 euid=0 suid=0
| |
| fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="iptables" exe="/sbin/iptables"
| |
| subj=unconfined_u:system_r:iptables_t:s0 key=(null)
| |
|
| |
|
| |
| Leave no stone unturned. Make them laugh, make them cry, make an impression. Sometimes when
| |
| explaining technical concepts to the uninitiated you must sacrifice being strictly accurate
| |
| in favor of getting the larger point across. Once the larger point is made then each person
| |
| can begin to work out the details but having the details without an appreciation of the larger
| |
| picture causes more problems than it solves.
| |
|
| |
|
| |
| Max
| |
| </pre>
| |
