Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

[Daniel J Walsh]

On 05/15/2015 05:05 PM, Paul Moore wrote:
> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs  wrote:
>>> On 15/05/14, Paul Moore wrote:
 * Look at our existing audit records to determine which records should
 have
 namespace and container ID tokens added.  We may only want to add the
 additional fields in the case where the namespace/container ID tokens are
 not the init namespace.
>>> If we have a record that ties a set of namespace IDs with a container
>>> ID, then I expect we only need to list the containerID along with auid
>>> and sessionID.
>> The problem here is that the kernel has no concept of a "container", and I
>> don't think it makes any sense to add one just for audit.  "Container" is a
>> marketing term used by some userspace tools.
>>
>> I can imagine that both audit could benefit from a concept of a
>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>> something along those lines).  Mapping these to "containers" belongs
>> in userspace, I think.
> It might be helpful to climb up a few levels in this thread ...
>
> I think we all agree that containers are not a kernel construct.  I further 
> believe that the kernel has no business generating container IDs, those 
> should 
> come from userspace and will likely be different depending on how you define 
> "container".  However, what is less clear to me at this point is how the 
> kernel should handle the setting, reporting, and general management of this 
> container ID token.
>
Wouldn't the easiest thing be to just treat add a containerid to the
process context like auid.  Then
make it a privileged operation to set it.  Then tools that care about
auditing like docker can set the ID
and remove the Capability from it sub processes if it cares.  All
processes adopt parent processes containerid.
Now containers can be audited and as long as userspace is written
correctly nested containers can either override the containerid or not
depending on what the audit rules are.

No special handling inside of namespaces.

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

[Daniel J Walsh]

On 05/14/2015 10:11 PM, Richard Guy Briggs wrote:
> On 15/05/14, Oren Laadan wrote:
>> On Thu, May 14, 2015 at 8:48 PM, Richard Guy Briggs  wrote:
>>
>> Recording each instance of a name space is giving me something that I
>> cannot use to do queries required by the security target. Given these
>> events, how do I locate a web server event where it accesses a
>>> watched
>> file? That authentication failed? That an update within the container
>> failed?
>>
>> The requirements are that we have to log the creation, suspension,
>> migration, and termination of a container. The requirements are not
>>> on
>> the individual name space.
> Ok.  Do we have a robust definition of a container?
 We call the combination of name spaces, cgroups, and seccomp rules a
 container.
>>> Can you detail what information is required from each?
>>>
> Where is that definition managed?
 In the thing that invokes a container.
>>> I was looking for a reference to a standards document rather than an
>>> application...
>>>
>>>
>> [focusing on "containers id" - snipped the rest away]
>>
>> I am unfamiliar with the audit subsystem, but work with namespaces in other
>> contexts. Perhaps the term "container" is overloaded here. The definition
>> suggested by Steve in this thread makes sense to me: "a combination of
>> namespaces". I imagine people may want to audit subsets of namespaces.
> I assume it would be a bit more than that, including cgroup and seccomp info.
I don't see why seccomp versus other Security mechanism come into this. 
Not really
sure of cgroup.  That stuff would all be associated with the process.  I
would guess
you could look at the process that modified these for logging, but that
should happen
at the time they get changed,  Not recorded for every process.
>> For namespaces, can use a string like "A:B:C:D:E:F" as an identifier for a
>> particular combination, where A-F are respective namespaces identifiers.
>> (Can be taken for example from /proc/PID/ns/{mnt,uts,ipc,user,pid,net}).
>>  That will even be grep-able to locate records related to a particular
>> subset
>> of namespaces. So a "container" in the classic meaning would have all A-F
>> unique and different from the init process, but processes separated only by
>> e.g. mnt-ns and net-ns will differ from the init process in  A and F.
>>
>> (If a string is a no go, then perhaps combine the IDs in a unique way into a
>> super ID).
> I'd be fine with either, even including the nsfs deviceID.
>
>> Oren.
> - RGB
>
> --
> Richard Guy Briggs 
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, 
> Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Granting CAP_AUDIT_WRITE to X/dbus/...

[Daniel J Walsh]

On 09/15/2014 09:57 AM, Steve Grubb wrote:
> On Monday, September 15, 2014 01:20:03 PM Laurent Bigonville wrote:
>> Hello,
>>
>> I was wondering now that the xserver can run as non-root shouldn't the
>> CAP_WRITE_AUDIT file capability be set on the Xorg executable?
> I can't imagine what the Xserver would need to do with auditing. If its 
> linked 
> against libaudit, then I guess it needs it. That said, no one has asked me to 
> review what the Xserver is doing wrt auditing. So, I have no idea if its 
> actually correctly done.
XAce?
>
>> Same question for AVC denials logging with dbus session bus[0]?
> That one I know needs to write events.
>
>
>> And in general, does anybody has an opinion about giving this
>> capability to $random executable?
> Yep, it should be done very cautiously. Some upstreams think audit is a 
> syslog 
> and just absolutely mess it up. Even upstreams that I helped get audit events 
> working eventually decide to make changes (for who knows what reason) and 
> then 
> I find out a year later that they messed things up.
>
> So, if auditing is being added to $random program, be suspicious and ask on 
> the list if this is known and correct. I am wanting to fix this by creating 
> some test suites that can help identify when programs change and start doing 
> the wrong thing.
>
> -Steve
>
>
>> Cheers,
>>
>> Laurent Bigonville
>>
>> [0] See: https://bugs.freedesktop.org/show_bug.cgi?id=83856
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [RFC][PATCH] selinux: Report result in avc messages

[Daniel J Walsh]

On 04/30/2014 09:29 AM, Steve Grubb wrote:
> On Wednesday, April 30, 2014 08:59:50 AM Daniel J Walsh wrote:
>> How about permitted rather then allowed.
> I think permitted is already in an AVC.
Not sure where.
>
>> On 04/29/2014 10:59 PM, Eric Paris wrote:
>>> On Tue, 2014-04-29 at 16:54 -0700, Stephen Smalley wrote:
>>>> Requested for Android in order to distinguish denials that are not in
>>>> fact breaking anything yet due to permissive domains versus denials
>>>> that are being enforced, but seems generally useful.  result field was
>>>> already in the selinux audit data structure and was being passed to
>>>> avc_audit() but wasn't being used.  Seems to cause no harm to ausearch
>>>> or audit2allow to add it as a field.  Comments?
>>> I think it's a great idea, but I'm worried that Steve is going to get
>>> grumpy because an AVC record is going to have a result= field which is
>>> similar, but not necessarily related to the res= field of a SYSCALL
>>> record. 
> I think that I'll have to parse this field no matter what. Its probably that 
> important. In the syscall, we use success= to be the final determination.
>
>
>>> Seems easily confused (although probably  times out of
>>> 1 they will be the same)
> Why would this ever not be correct? Are there times when we get an AVC with a 
> denial _and_ the syscall completes successfully?
>
> I'd suggest using res= since its in the audit dictionary and means exactly 
> what you are wanting to use it for. In it, 1 is success, 0 is failure.
>
I have seen AVC's where the success=yes in enforcing mode.  Basically
the kernel takes a different code path and the syscall succeeds.  Most
of these end up as dontaudits.
>>> So while I wholeheartedly think we should take the idea, I wonder if
>>> someone can dream up a name that isn't confusingly similar...
>>>
>>> I can't think of anything...
> There is thesaurus.com. :-)
>
> consequence, outcome, effect, reaction,  conclusion, verdict, decision, 
> judgement, finding, ruling, answer, solution, recommendation, order,  ...
>
> -Steve

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [RFC][PATCH] selinux: Report result in avc messages

[Daniel J Walsh]

How about permitted rather then allowed.

On 04/29/2014 10:59 PM, Eric Paris wrote:
> On Tue, 2014-04-29 at 16:54 -0700, Stephen Smalley wrote:
>> Requested for Android in order to distinguish denials that are not in
>> fact breaking anything yet due to permissive domains versus denials
>> that are being enforced, but seems generally useful.  result field was
>> already in the selinux audit data structure and was being passed to
>> avc_audit() but wasn't being used.  Seems to cause no harm to ausearch
>> or audit2allow to add it as a field.  Comments?
> I think it's a great idea, but I'm worried that Steve is going to get
> grumpy because an AVC record is going to have a result= field which is
> similar, but not necessarily related to the res= field of a SYSCALL
> record.  Seems easily confused (although probably  times out of
> 1 they will be the same)
>
> So while I wholeheartedly think we should take the idea, I wonder if
> someone can dream up a name that isn't confusingly similar...
>
> I can't think of anything...
>
> -Eric
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 0/6][v2] audit: implement multicast socket for journald

[Daniel J Walsh]

I don't disagree.  I would think the real solution to this would be to
not allow sysadm_t to get to SystemHigh, where all of the logging data
will be stored.

On 04/24/2014 09:22 AM, Eric Paris wrote:
> They would be equivalent if and only if journald had CAP_AUDIT_READ.
>
> I suggest you take CAP_AUDIT_READ away from journald on systems which
> need the secadm/sysadmin split (which is a ridiculously stupid split
> anyway, but who am I to complain?)
>
> On Wed, Apr 23, 2014 at 11:52 AM, Daniel J Walsh  wrote:
>> Meaning looking at the journal would be equivalent to looking at
>> /var/log/audit/audit.log.
>>
>>
>> On 04/23/2014 11:37 AM, Eric Paris wrote:
>>> On Wed, 2014-04-23 at 11:36 -0400, Daniel J Walsh wrote:
>>>> I guess the problem would be that the sysadm_t would be able to look at
>>>> the journal which would now contain the audit content.
>>> right.  so include it in the sysadm_secadm bool
>>>
>>>> On 04/23/2014 10:42 AM, Eric Paris wrote:
>>>>> On Wed, 2014-04-23 at 09:40 -0400, Daniel J Walsh wrote:
>>>>>> Here are the capabilities we currently give to sysadm_t with
>>>>>> sysadm_secadm1.0.0Disabled
>>>>>>
>>>>>>allow sysadm_t sysadm_t : capability { chown dac_override
>>>>>> dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable
>>>>>> net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
>>>>>> sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice
>>>>>> sys_resource sys_time sys_tty_config mknod lease audit_write setfcap } ;
>>>>>>allow sysadm_t sysadm_t : capability { setgid setuid sys_chroot }
>>>>>>
>>>>>>allow sysadm_t sysadm_t : capability2 { syslog block_suspend } ;
>>>>>>
>>>>>> cap_audit_write might be a problem?
>>>>> cap_audit_write is fine.
>>>>>
>>>>> syslogd_t (aka journal) is going to need the new permission
>>>>> cap_audit_read.  Also, as steve pointed out, someone may be likely to
>>>>> want to be able to disable that permission easily.
>>>>>
>>>>> -Eric
>>>>>
>>> ___
>>> Selinux mailing list
>>> seli...@tycho.nsa.gov
>>> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>>> To get help, send an email containing "help" to 
>>> selinux-requ...@tycho.nsa.gov.
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> ___
> Selinux mailing list
> seli...@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
>
>

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 0/6][v2] audit: implement multicast socket for journald

[Daniel J Walsh]

Yes that would be the long term fix.  But it would involve journal
labelling individual data records.  IE Records from audit.log would be
audit_log_t, while messages from syslog would be var_log_t,  Or some
other kind of crazyness.


On 04/24/2014 11:03 AM, Eric Paris wrote:
> On Thu, 2014-04-24 at 10:59 -0400, Daniel J Walsh wrote:
>> I don't disagree.  I would think the real solution to this would be to
>> not allow sysadm_t to get to SystemHigh, where all of the logging data
>> will be stored.
> make journalctl a userspace object manager and do selinux checks on if
> it can see individual records?  so secadm_t running journalctl would see
> them and sysadm running journalctl wouldn't see them?
>
> Sounds elegant.  Who is going to code it?  *NOT IT!*
>
>> On 04/24/2014 09:22 AM, Eric Paris wrote:
>>> They would be equivalent if and only if journald had CAP_AUDIT_READ.
>>>
>>> I suggest you take CAP_AUDIT_READ away from journald on systems which
>>> need the secadm/sysadmin split (which is a ridiculously stupid split
>>> anyway, but who am I to complain?)
>>>
>>> On Wed, Apr 23, 2014 at 11:52 AM, Daniel J Walsh  wrote:
>>>> Meaning looking at the journal would be equivalent to looking at
>>>> /var/log/audit/audit.log.
>>>>
>>>>
>>>> On 04/23/2014 11:37 AM, Eric Paris wrote:
>>>>> On Wed, 2014-04-23 at 11:36 -0400, Daniel J Walsh wrote:
>>>>>> I guess the problem would be that the sysadm_t would be able to look at
>>>>>> the journal which would now contain the audit content.
>>>>> right.  so include it in the sysadm_secadm bool
>>>>>
>>>>>> On 04/23/2014 10:42 AM, Eric Paris wrote:
>>>>>>> On Wed, 2014-04-23 at 09:40 -0400, Daniel J Walsh wrote:
>>>>>>>> Here are the capabilities we currently give to sysadm_t with
>>>>>>>> sysadm_secadm1.0.0Disabled
>>>>>>>>
>>>>>>>>allow sysadm_t sysadm_t : capability { chown dac_override
>>>>>>>> dac_read_search fowner fsetid kill setgid setuid setpcap 
>>>>>>>> linux_immutable
>>>>>>>> net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
>>>>>>>> sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice
>>>>>>>> sys_resource sys_time sys_tty_config mknod lease audit_write setfcap } 
>>>>>>>> ;
>>>>>>>>allow sysadm_t sysadm_t : capability { setgid setuid sys_chroot }
>>>>>>>>
>>>>>>>>allow sysadm_t sysadm_t : capability2 { syslog block_suspend } ;
>>>>>>>>
>>>>>>>> cap_audit_write might be a problem?
>>>>>>> cap_audit_write is fine.
>>>>>>>
>>>>>>> syslogd_t (aka journal) is going to need the new permission
>>>>>>> cap_audit_read.  Also, as steve pointed out, someone may be likely to
>>>>>>> want to be able to disable that permission easily.
>>>>>>>
>>>>>>> -Eric
>>>>>>>
>>>>> ___
>>>>> Selinux mailing list
>>>>> seli...@tycho.nsa.gov
>>>>> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>>>>> To get help, send an email containing "help" to 
>>>>> selinux-requ...@tycho.nsa.gov.
>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majord...@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>> ___
>>> Selinux mailing list
>>> seli...@tycho.nsa.gov
>>> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
>>> To get help, send an email containing "help" to 
>>> selinux-requ...@tycho.nsa.gov.
>>>
>>>
>
> ___
> Selinux mailing list
> seli...@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
>
>

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 0/6][v2] audit: implement multicast socket for journald

[Daniel J Walsh]

Meaning looking at the journal would be equivalent to looking at
/var/log/audit/audit.log.


On 04/23/2014 11:37 AM, Eric Paris wrote:
> On Wed, 2014-04-23 at 11:36 -0400, Daniel J Walsh wrote:
>> I guess the problem would be that the sysadm_t would be able to look at
>> the journal which would now contain the audit content.
> right.  so include it in the sysadm_secadm bool
>
>> On 04/23/2014 10:42 AM, Eric Paris wrote:
>>> On Wed, 2014-04-23 at 09:40 -0400, Daniel J Walsh wrote:
>>>> Here are the capabilities we currently give to sysadm_t with
>>>> sysadm_secadm1.0.0Disabled
>>>>
>>>>allow sysadm_t sysadm_t : capability { chown dac_override
>>>> dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable
>>>> net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
>>>> sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice
>>>> sys_resource sys_time sys_tty_config mknod lease audit_write setfcap } ;
>>>>allow sysadm_t sysadm_t : capability { setgid setuid sys_chroot }
>>>>
>>>>allow sysadm_t sysadm_t : capability2 { syslog block_suspend } ;
>>>>
>>>> cap_audit_write might be a problem?
>>> cap_audit_write is fine.
>>>
>>> syslogd_t (aka journal) is going to need the new permission
>>> cap_audit_read.  Also, as steve pointed out, someone may be likely to
>>> want to be able to disable that permission easily.
>>>
>>> -Eric
>>>
>
> ___
> Selinux mailing list
> seli...@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
>
>

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 0/6][v2] audit: implement multicast socket for journald

[Daniel J Walsh]

I guess the problem would be that the sysadm_t would be able to look at
the journal which would now contain the audit content.

On 04/23/2014 10:42 AM, Eric Paris wrote:
> On Wed, 2014-04-23 at 09:40 -0400, Daniel J Walsh wrote:
>> Here are the capabilities we currently give to sysadm_t with
>> sysadm_secadm1.0.0Disabled
>>
>>allow sysadm_t sysadm_t : capability { chown dac_override
>> dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable
>> net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
>> sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice
>> sys_resource sys_time sys_tty_config mknod lease audit_write setfcap } ;
>>allow sysadm_t sysadm_t : capability { setgid setuid sys_chroot }
>>
>>allow sysadm_t sysadm_t : capability2 { syslog block_suspend } ;
>>
>> cap_audit_write might be a problem?
> cap_audit_write is fine.
>
> syslogd_t (aka journal) is going to need the new permission
> cap_audit_read.  Also, as steve pointed out, someone may be likely to
> want to be able to disable that permission easily.
>
> -Eric
>

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [PATCH 0/6][v2] audit: implement multicast socket for journald

[Daniel J Walsh]

Here are the capabilities we currently give to sysadm_t with
sysadm_secadm1.0.0Disabled

   allow sysadm_t sysadm_t : capability { chown dac_override
dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable
net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice
sys_resource sys_time sys_tty_config mknod lease audit_write setfcap } ;
   allow sysadm_t sysadm_t : capability { setgid setuid sys_chroot }

   allow sysadm_t sysadm_t : capability2 { syslog block_suspend } ;

cap_audit_write might be a problem?

On 04/22/2014 11:57 PM, Eric Paris wrote:
> On Tue, 2014-04-22 at 22:25 -0400, Steve Grubb wrote:
>> On Tuesday, April 22, 2014 09:31:52 PM Richard Guy Briggs wrote:
>>> This is a patch set Eric Paris and I have been working on to add a
>>> restricted capability read-only netlink multicast socket to kernel audit to
>>> enable userspace clients such as systemd/journald to receive audit logs, in
>>> addition to the bidirectional auditd userspace client.
>> Do have the ability to separate of secadm_r and sysadm_r? By allowing this, 
>> we 
>> will leak to a sysadmin that he is being audited by the security officer. In 
>> a 
>> lot of cases, they are one in the same person. But for others, they are not. 
>> I 
>> have a feeling this will cause problems for MLS systems.
> Why?  This requires CAP_AUDIT_READ.  Just don't give CAP_AUDIT_READ to
> places you don't want to have read permission.  Exactly the same as you
> don't give CAP_AUDIT_CONTROL to sysadm_r.  (If we are giving
> CAP_AUDIT_CONTROL to sysadm_r and you think that any file protections
> on /var/log/audit/audit.log are adequate we are fooling ourselves!)
>
>> Also, shouldn't we have an audit event for every attempt to connect to this 
>> socket? We really need to know where this information is getting leaked to.
> We certainly can.  What would you like to see in that event?
>
> -Eric
>
> ___
> Selinux mailing list
> seli...@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
>
>

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: Place to call pam_loginuid in the pam session stack

[Daniel J Walsh]

On 04/22/2014 02:59 PM, Steve Grubb wrote:
> On Tuesday, April 22, 2014 07:30:44 PM Laurent Bigonville wrote:
>> Hello,
>>
>> This is maybe a dumb question, but is there any preferred place in the
>> pam session stack to call pam_loginuid?
>>
>> Is it preferable to call it just after "pam_selinux close" or is any
>> place OK? I guess the sooner the better so the needed information are
>> present to audit what the other pam modules are doing?
> I think that as long as its set before a user can cause any action to occur 
> on 
> their behalf is all that is required. If there is a pam module that looks in 
> a 
> user's home directory for settings and then does something based on that, 
> then 
> you'd need to set it before that module.
>
> -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
Well that is the goal of pam_selinux open also.  So it should either be
right before or right after. 

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: [Part1 PATCH 00/22] Add namespace support for audit

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/20/2013 11:48 PM, Gao feng wrote:
> On 06/20/2013 09:02 PM, Eric Paris wrote:
>> On Thu, 2013-06-20 at 11:02 +0800, Gao feng wrote:
>>> On 06/20/2013 04:51 AM, Eric Paris wrote:
 On Wed, 2013-06-19 at 16:49 -0400, Aristeu Rozanski wrote:
> On Wed, Jun 19, 2013 at 09:53:32AM +0800, Gao feng wrote:
>> This patchset is first part of namespace support for audit. in
>> this patchset, the mainly resources of audit system have been
>> isolated. the audit filter, rules havn't been isolated now. It
>> will be implemented in Part2. We finished the isolation of user
>> audit message in this patchset.
>> 
>> I choose to assign audit to the user namespace. Right now,there
>> are six kinds of namespaces, such as net, mount, ipc, pid, uts
>> and user. the first five namespaces have special usage. the audit
>> isn't suitable to belong to these five namespaces, And since the
>> flag of system call clone is in short supply, we can't provide a
>> new flag such as CLONE_NEWAUDIT to enable audit namespace
>> separately. so the user namespace may be the best choice.
> 
> I thought it was said on the last submission that to tie userns
> and audit namespace would be a bad idea?
 
 I consider it a non-starter.  unpriv users are allowed to launch
 their own user namespace.  The whole point of audit is to have only a
 priv user be allowed to make changes.  If you tied audit namespace to
 user namespace you grant an unpriv user the ability to modify audit.
 
>>> 
>>> I understand your views.
>>> 
>>> But ven the unpriv user are allowed to make changes, they can do no
>>> harm. they can only make changes on the audit namespace they
>>> created.they can only communicate with the audit namespace they
>>> created.
>> 
>> Imagine I set up my machine to audit all user access to super secret 
>> information.  With your patch set all an malicious user has to do is 
>> create a new user namespace.  Now when he accesses the super secret 
>> information it will be logged inside the user namespace he created.  So 
>> he can just dump those logs in the trash.
>> 
> 
> No, my v1 patchset only log the user audit message(which generated through 
> auditctl -m "xxx") inside user namespace.
> 
> I agree with that we should not simply log audit message in the child audit
> namespace. for some global resource related audit messages, they should be
> logged in init audit namespace too.
> 
>> I believe that each audit namespace should require priv 
>> (CAP_AUDIT_CONTROL) in the user namespace that created the current audit 
>> namespace.  So lets say the machine boots and we are in the init_user and
>> init_audit namespace.  Creating a new audit namespace should require 
>> CAP_AUDIT_CONTROL in the init_user namespace.  If instead we spawned a 
>> new user namespace userns1 and try to create a new audit namespace, we 
>> should STILL check for CAP_AUDIT_CONTROL in the init_user namespace.
>> 
> 
> Ok, I can add this permission check in next version, though this seems a 
> litter strictness when we make sure child audit namespace won't fool the 
> init audit namespace,
> 
>> Assuming we've spawned auditns1 in userns1 and want to spawn auditns2 it 
>> should require CAP_AUDIT_CONTROL in userns1.  So now you only have 
>> permission to change your audit config (create a new audit namespace) if 
>> you already had permission to change your current audit config.
>> 
>> Now how to handle coding this...
>> 
>> When the kernel receives an audit message on the netlink socket it can 
>> always check the current->[whatever] to figure out which audit namespace 
>> it came from.  Then it can be processed accordingly...
> 
> Yes, this situation is easy to handle, since we are in process context... 
> but in some situations, we are not running in process context... as I 
> mentioned, audit messages generated by netfilter rules. current process is
> untrustable. we can only get meaningful net namespace in this situation. 
> Actually, it's meaningful to send net related audit messages to the user 
> namespace which creates this net namespace.
> 
> 
>> 
>> Sending messages to the userspace auditd is a little more tricky.  We 
>> need to somehow map the audit namespace to a socket connected to auditd 
>> in userspace.  I'd imagine we'd have to either have per auditns backlog 
>> queues and run one kauditd per audit namespace, or we'd have to tag the 
>> skb's with the intended namespace somehow and then find the right socket 
>> in kauditd.  Either way it doesn't seem too onerous (although I admit, I 
>> don't know how to code the per namespace kauditd right offhand)
>> 
> 
> As I said in "[PATCH 04/22] netlink: Add compare function for
> netlink_table", netlink and socket are private resources of net namespace.
> socket has no idea which audit namespace it belongs to,unless we add a
> field to mark this. Through I think we can

Re: missing user name

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/31/2012 04:33 PM, Harris, Todd wrote:
> We are using a product called Likewise, which was purchased by beyond
> trust.  I don?t know if I mentioned it before but the system works on the
> other rhel nodes we have.
> 
> 
Any SELinux issues?
> 
> *From:*Saunders, Thomas D. II [mailto:thomas.d.saunders...@saic.com] 
> *Sent:* Tuesday, July 31, 2012 3:16 PM *To:* Harris, Todd;
> linux-audit@redhat.com *Subject:* RE: missing user name
> 
> 
> 
> Are you using OpenLDAP to connect to MS AD servers?
> 
> 
> 
> Tom Saunders | SAIC Senior Information Assurance & Security Engineer phone:
> 540-653-0986 | fax 540-663-0640
> 
> mobile: 540-408-3087| email: saunde...@saic.com
>  SIPRnet: thomas.d.saund...@us.army.smil.mil 
> 
> 
> SIPRnet: thomas.saund...@navy.smil.mil
> 
> 
> 
> 
> Science Applications International Corporation SAIC 16442 Commerce Drive 
> King George, VA  22485
> 
> www.saic.com 
> 
> 
> 
> 
> 
> 
>
>  *From:*linux-audit-boun...@redhat.com
>  on behalf of Harris, Todd *Sent:*
> Tue 7/31/2012 3:06 PM *To:* linux-audit@redhat.com
>  *Subject:* missing user name
> 
> I?m looking at a problem that has me really scratching my head.
> 
> 
> 
> I?ve got a rhel 5.4 system that?s using likewise and active directory to 
> authenticate users, at least ones that are not defined locally.  Locally
> defined users work just fine, but any user that is defined in the active
> directory server is showing up in events as ?unknown(uid)? the uid appears
> to be filled out correctly, and if the user is defined locally as well as
> in active directory it works just fine, but that kind of defeats the
> purpose.  Also failed logins are showing up correctly, but I can?t figure
> out what they have done to their system to cause this.  Can anyone give me
> a little direction on where I should look to determine what?s actually
> going on.  I haven?t been able to determine how the system actually
> resolves the user names.
> 
> 
> 
> Don?t know if this is important but we are using the prelude plugin and
> where we notice the discrepancy is in the output from the prelude-manager,
> I have not looked to see if it?s wrong in the aureords.
> 
> 
> 
> ___
> 
> Todd Harris
> 
> Progeny Systems
> 
> Office Number: 703-368-6107 ext517
> 
> 
> 
> 
> 
> 
> 
> -- Linux-audit mailing list Linux-audit@redhat.com 
> https://www.redhat.com/mailman/listinfo/linux-audit
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAZIU8ACgkQrlYvE4MpobPxqgCguRHT0pqj8ZkRzyOTGrOm9BNP
PM0AoKDWAtY8OVQqzJbcM9QGQJmrDfzc
=cCap
-END PGP SIGNATURE-

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: auditing syscalls made 'by' an inode?

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/08/2012 09:51 AM, Steve Grubb wrote:
> On Friday, June 08, 2012 09:35:01 AM Steve Grubb wrote:
>> On Thursday, June 07, 2012 06:31:47 PM Peter Moody wrote:
>>> Is there anyway to audit syscalls made by a particular, not yet 
>>> running, application?
>> 
>> No...its one of the things I've been interested in for a long time.
>> About as close as you get is using the selinux process context. But if
>> its bin_t...there's a couple thousand processes with the same label.
>> 
>>> For example, if I'm interested in seeing all exec's by google-chrome,
>>> can I do something like the following?
>>> 
>>> auditctl -a exit,always -F arch=b64 -S execve -F success=1 -F 
>>> inode=inode-of-chrome
>>> 
>>> experimenting seems to indicate that will only tell me when 
>>> inode-of-chrome is exec'd, basically a watch rule.
>>> 
>>> The sort of inverse of this rule that got me thinking about this 
>>> initially was auditing a syscall and seeing if it was/wasn't called by 
>>> a particular program. For example, audting all bind() calls which 
>>> *aren't* made by chrome (a silly rule to be sure, but just thrown out 
>>> as a hypothetical)
>>> 
>>> If it's not possible to do this now, is there interest in adding this 
>>> feature?
>> 
>> Yes. I'd be interested in seeing this available. But if you do implement 
>> it, its more natural to express the rule by process name. But the kernel 
>> does not do string comparisons. So, what you would likely need to do is 
>> lookup the path to get the inode, then when it executes a new kind of
>> pid rule gets created probably off the list like watches do. There are
>> some apps like apache which fork multiple copies and that adds a wrinkle 
>> because you would want to audit all of them. And then there are 
>> threads...
> 
> The other thing that was discussed a lot maybe 5 years ago (and I don't
> think it was ever created) was the ability to audit syscalls of a processes
> children and their children...on and on.  I think Al Viro mentioned he had
> some ideas about how to do this. But if you add audit by process name, its
> only natural to optionally track all child processes, too.
> 
> Where you might want this is like setting a rule on apache for any EPERM or
> any access to /home. Same could go for bind.
> 
> -Steve
> 
> -- Linux-audit mailing list Linux-audit@redhat.com 
> https://www.redhat.com/mailman/listinfo/linux-audit
> 
On thing you could do would be to write a simple SELinux domain, like
auditproc_t and have unconfined_t transition to it using runcon.

type auditproc_t;
domain_type(auditproc_t);
unconfined_domain(auditproc_t)
gen_require(`
type unconfined_t;
type unconfined_r;
')

allow unconfined_t auditproc_t:process transition;
role unconfined_r types auditproc_t;



Setup audit rules to watch SELinux context auditproc_t.


Then use runcon -t auditproc_t chrome

Above is totally untested.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/SEQwACgkQrlYvE4MpobPO5QCgxjoEHO4F3tr6GWFPdBumCTkC
kDcAn0+BhECihfFwlnjDHLoYw2WPnkvr
=3vLI
-END PGP SIGNATURE-

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit log not being rotated

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/04/2010 02:30 PM, Mike Williams wrote:
> On Sat, Sep 4, 2010 at 1:52 PM, Dominick Grift  wrote:
> 
>> On Sat, Sep 04, 2010 at 01:24:33PM -0400, Mike Williams wrote:
>>>
>>> Any idea why one box out of three would behave differently?  It is a
>>> worrisome difference.
>>
>> Audit does not use logrotate to rotate logs. I think it does that itself.
>> See /etc/audit/auditd.conf
>> Also the log can be rotated by running the auditd rc script: service auditd
>> rotate
>>
>>
> After lots of digging and, confirmed by your response, I now realize that
> logrotate is not being used.  The cron file I mentioned uses the command you
> mentioned (service auditd rotate) to rotate the logs.
> 
> I just compared /etc/auditd.conf and /etc/audit.rules on the system that was
> not rotating logs with one of the ones that has been rotating audit.log and
> they are identical.
> 
> So, for me, my original question remains a puzzle.  Why did it just work on
> two out of three boxes, but require adding a cron job to do "service auditd
> rotate" on the the third.  Murphy's Law is in force here, the system that
> has not been rotating the logs is the one that is the most important, at
> least in terms of the number of people who use it.
> 
> Mainly I'm concerned about what will happen on the update to f14, since the
> misbehaving system is now fixed.
> 
> Mike
> 
> 
> 
> 
> --
> selinux mailing list
> seli...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
I would ask on the audit list.linux-au...@redhat.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkyGUlYACgkQrlYvE4MpobO2PgCbBarqt+aP+DFjo8/1IjwyY4sr
xfMAoL3zY1LvfoKNQtguhD5CGcLHxiUU
=kKWv
-END PGP SIGNATURE-

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: How do I figure out on what file dac_override is attempted?

[Daniel J Walsh]

On 01/20/2010 02:50 PM, Stephen Smalley wrote:
> type=PATH msg=audit(01/20/2010 14:43:20.785:41253) : item=0 
> name=./capable_file/temp_file inode=841249 dev=fd:00 mode=file,644 ouid=root 
> ogid=root rdev=00:00 obj=unconfined_u:object_r:test_file_t:s0 

Why does path begin with a ./capable_file/temp_file?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: How do I figure out on what file dac_override is attempted?

[Daniel J Walsh]

On 01/20/2010 11:15 AM, Joshua Brindle wrote:
> Stephen Smalley wrote:
>> On Wed, 2010-01-20 at 10:12 -0500, Daniel J Walsh wrote:
>>> On 01/20/2010 08:51 AM, Stephen Smalley wrote:
>>>> On Wed, 2010-01-20 at 13:47 +0100, Göran Uddeborg wrote:
>>>>> Stephen Smalley:
>>>>>> To get object information, you need to enable
>>>>>> syscall auditing, and add a trivial syscall filter to turn on
>>>>>> pathname
>>>>>> collection by the audit subsystem.
>>>>> Thanks for that tip (all of you who gave it)!  I now know it is
>>>>> /dev/fb that plymouthd can't access.  The audit record also told me it
>>>>> was owned by a regular user and mode rw---.  So now it makes
>>>>> sense.  A root process would need dac_override to open that file.
>>>> That tip really ought to get captured in the Fedora SELinux FAQ or
>>>> Guide.  Dan?
>>>>
>>> You mean turning on full auditing if you have a suspicious DAC_OVERRIDE?
>>
>> More generally, if you want full pathname information for an AVC denial
>> and you aren't getting it in the AVC message, you can get it by adding a
>> trivial audit syscall filter and re-trying the operation, where adding a
>> trivial audit syscall filter can be done by any of the three examples
>> given by Steve Grubb, Eric, or myself - take your pick.  It can be done
>> temporarily just by running auditctl or on every boot by adding the
>> entry to /etc/audit/audit.rules.
>>
> 
> Can we add it to selinuxproject.org instead (or in addition to, I guess?)

Here is my blog on it.

http://danwalsh.livejournal.com/34903.html

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: How do I figure out on what file dac_override is attempted?

[Daniel J Walsh]

On 01/20/2010 08:51 AM, Stephen Smalley wrote:
> On Wed, 2010-01-20 at 13:47 +0100, Göran Uddeborg wrote:
>> Stephen Smalley:
>>> To get object information, you need to enable
>>> syscall auditing, and add a trivial syscall filter to turn on pathname
>>> collection by the audit subsystem.
>>
>> Thanks for that tip (all of you who gave it)!  I now know it is
>> /dev/fb that plymouthd can't access.  The audit record also told me it
>> was owned by a regular user and mode rw---.  So now it makes
>> sense.  A root process would need dac_override to open that file.
> 
> That tip really ought to get captured in the Fedora SELinux FAQ or
> Guide.  Dan?
> 

You mean turning on full auditing if you have a suspicious DAC_OVERRIDE?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: How do I figure out on what file dac_override is attempted?

[Daniel J Walsh]

On 01/19/2010 09:52 AM, Stephen Smalley wrote:
> On Mon, 2010-01-18 at 22:05 +0100, Göran Uddeborg wrote:
>> Here is another strange AVC I'm trying to understand.
>>
>> SETroubleshoot on one of my machines is telling me that
>>
>>   SELinux is preventing plymouthd (plymouthd_t) "dac_override" plymouthd_t.
>>
>> The full message is attached.
>>
>> If I have understood this correctly, this means that plymouthd was
>> trying to read a file as root.  But the regular permissions bits of
>> the file would not allow that.  (Right?)
>>
>> I assume there is some file with wrong permission bits, which causes
>> this to happen.  But I can't find any indication WHAT file it was.
>> Looking at the message, it seems to me it was trying a dac_override on
>> itself.
>>
>> Is there a way to know what file was involved?
> 
> The capability checks in Linux do not pass the object to the security
> module, so SELinux only knows about the current task and the particular
> capability requested.  To get object information, you need to enable
> syscall auditing, and add a trivial syscall filter to turn on pathname
> collection by the audit subsystem.  Then re-try the operation that
> generated the denial.
> 
> auditctl -s
> will show the current status of the audit system.
> 
> auditctl -a exit,always -S chroot
> is an example syscall filter.
> 
> The filter doesn't need to have anything to do with your failing
> operation - it just turns on the machinery that will cause pathname
> collection so that when the AVC is generated, you will also get a
> SYSCALL record with the pathname info.
> 
So there is no easy way in the kernel to get this information into the AVC 
without taking the overhead hit of 
full path auditing.

> The capability checks in Linux do not pass the object to the security
> module, so SELinux only knows about the current task and the particular
> capability requested.

Would this be insanity to ask that the object be passed to the capability check?

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: restorecon resets files

[Daniel J Walsh]

LC Bruzenak wrote:
> # ls -Z /var/run/auditd.pid /var/run/audispd_events
> srw-r-  root root system_u:object_r:audisp_var_run_t:SystemHigh 
> /var/run/audispd_events
> -rw-r--r--  root root system_u:object_r:auditd_var_run_t:SystemHigh 
> /var/run/auditd.pid
> 
> # restorecon -rv /var/run/
> restorecon reset /var/run/audispd_events context 
> system_u:object_r:audisp_var_run_t:s15:c0.c1023->system_u:object_r:audisp_var_run_t:s0
> restorecon reset /var/run/auditd.pid context 
> system_u:object_r:auditd_var_run_t:s15:c0.c1023->system_u:object_r:auditd_var_run_t:s0
> 
> [EMAIL PROTECTED] ~]# ls -Z /var/run/auditd.pid /var/run/audispd_events
> srw-r-  root root system_u:object_r:audisp_var_run_t:SystemLow 
> /var/run/audispd_events
> -rw-r--r--  root root system_u:object_r:auditd_var_run_t:SystemLow 
> /var/run/auditd.pid
> 
> I assume that both these files should be kept at SystemHigh?
> 
> selinux-policy-mls-3.4.2-14.fc9.noarch
> 
> Thx,
> LCB.
> 
Yes that is a bug.

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

avc_snap a python tool that grabs Audit messages from the auditd.

[Daniel J Walsh]

We are building a tool that will try to diagnose an AVC Message and tell 
the administrator what it means. 

To do this I have written a fairly simple python script that grabs the 
dispatcher message from the audit daemon and then formats
python dictionary which will eventually be handed off to the analyzer 
code. 


Dan

#!/usr/bin/python
# Copyright (C) 2006 Red Hat, Inc
# Author by Dan Walsh, <[EMAIL PROTECTED]>
#
# 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; either version 2 of the License, or
# (at your option) any later version.
#
# 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
#
# avc_snap - this script is is launched by the auditd and listense on
# stdin for Audit messages. It then searches for AVC Messages and assembles
# them into a python dictionary for later processing by the AVC Plugins
#
#

import os, string, select, struct, syslog
# audit python provided by audit-python package
# avc python provided by policycoreutils package
import audit, avc

#
# Collect a list of audit messages until a timeout or the audit signature 
changes
# Check to see if the list contains an AUDIT_AVC message
# If yes
# create the dictionary using serules.
# For now just syslog the dictionary,
# eventually will call analyze and process avc message
# else
# discard
# 
class avc_snap:
def __init__(self):
self.audit_list = []
self.cur_sig = ""

def is_avc(self):
for i in self.audit_list:
if i[0] == audit.AUDIT_AVC:
return True
return False

def out(self):
if self.is_avc():
rules=avc.SERules()
l=[]
for ( type, data_list ) in self.audit_list:
l  += data_list
syslog.syslog("data %s" % 
string.join(data_list, " "))
rules.translate(l)
for dict in rules.AVCS:
for d in dict.keys():
syslog.syslog("%s->%s" % (d, dict[d]))
self.audit_list = []

def process(self, type, data):
data_list=data.split()
new_sig=data_list[0]

if len(self.audit_list) > 0 and new_sig != self.cur_sig:
self.out()
self.cur_sig = new_sig

self.audit_list.append((type, data_list[1:]))

def run(self):
while 1:
input,output, err = select.select([0],[], [], 5)
try:
if 0 in input:
baseformat=""
theline=os.read(0,16 + 
audit.MAX_AUDIT_MESSAGE_LENGTH)
numremain = 
len(theline)-struct.calcsize(baseformat)
format = "%s%ds" % (baseformat, 
numremain)
version, size, type, length, data = 
struct.unpack(format, theline)
#   syslog.syslog("append type=%d data %s" 
% (type,data[:length]))
self.process(type, data[:length])
else:
self.out()

except struct.error, e:
syslog.syslog("struct exception %s " % e.args)
except TypeError, e:
syslog.syslog("Type exception %s " % e.args)

try:
snap=avc_snap()
snap.run()

except IOError,e:
syslog.syslog("IOError exception %s" % e.args)

except Exception, e:
syslog.syslog("Unexpected exception %s " % e.args)
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit