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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <535935ED.8050707@redhat.com>
Date:	Thu, 24 Apr 2014 12:03:57 -0400
From:	Daniel J Walsh <dwalsh@...hat.com>
To:	Eric Paris <eparis@...hat.com>
CC:	Linux Netdev List <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	linux-audit@...hat.com, SE-Linux <selinux@...ho.nsa.gov>,
	jamal@...atatu.com, Steve Grubb <sgrubb@...hat.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH 0/6][v2] audit: implement multicast socket for journald

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 <dwalsh@...hat.com> 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_secadm    1.0.0    Disabled
>>>>>>>>
>>>>>>>>    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
>>>>> Selinux@...ho.nsa.gov
>>>>> To unsubscribe, send email to Selinux-leave@...ho.nsa.gov.
>>>>> To get help, send an email containing "help" to Selinux-request@...ho.nsa.gov.
>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo@...r.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
>>> Selinux@...ho.nsa.gov
>>> To unsubscribe, send email to Selinux-leave@...ho.nsa.gov.
>>> To get help, send an email containing "help" to Selinux-request@...ho.nsa.gov.
>>>
>>>
>
> _______________________________________________
> Selinux mailing list
> Selinux@...ho.nsa.gov
> To unsubscribe, send email to Selinux-leave@...ho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@...ho.nsa.gov.
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/