Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758667AbaDXQEJ (ORCPT ); Thu, 24 Apr 2014 12:04:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21600 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758260AbaDXQED (ORCPT ); Thu, 24 Apr 2014 12:04:03 -0400 Message-ID: <535935ED.8050707@redhat.com> Date: Thu, 24 Apr 2014 12:03:57 -0400 From: Daniel J Walsh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Paris CC: Linux Netdev List , Linux Kernel Mailing List , LSM List , linux-audit@redhat.com, SE-Linux , jamal@mojatatu.com, Steve Grubb , David Miller Subject: Re: [PATCH 0/6][v2] audit: implement multicast socket for journald References: <20140422.161904.1187535812839850973.davem@davemloft.net> <26389161.vp9iWSVLPX@x2> <1398225475.750.7.camel@localhost> <5357C2D2.5060700@redhat.com> <1398264152.2596.25.camel@flatline.rdu.redhat.com> <5357DE12.7040905@redhat.com> <1398267458.2562.0.camel@flatline.rdu.redhat.com> <5357E1B4.2030705@redhat.com> <535926B8.7060304@redhat.com> <1398351780.750.10.camel@localhost> In-Reply-To: <1398351780.750.10.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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_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@tycho.nsa.gov >>>>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>>>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. >>>>> >>>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >>>> the body of a message to majordomo@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 >>> Selinux@tycho.nsa.gov >>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. >>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. >>> >>> > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/