[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5357DE12.7040905@redhat.com>
Date: Wed, 23 Apr 2014 11:36:50 -0400
From: Daniel J Walsh <dwalsh@...hat.com>
To: Eric Paris <eparis@...hat.com>
CC: Steve Grubb <sgrubb@...hat.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-audit@...hat.com,
selinux@...ho.nsa.gov, jamal@...atatu.com, davem@...emloft.net
Subject: Re: [PATCH 0/6][v2] audit: implement multicast socket for journald
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_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
>
--
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/
Powered by blists - more mailing lists