On Wednesday, September 6, 2017 9:42:53 AM EDT Maupertuis Philippe wrote:
> Hi,
> The examples found in the audit documentation mention that to work it is
> assumed that no direct root login is allowed. This very sensible and not a
> big problem except for console access.
Why is it a problem for c
Hello Jan,
On Wednesday, September 6, 2017 12:48:21 PM EDT Jan Kara wrote:
> On Wed 06-09-17 10:35:32, Steve Grubb wrote:
> > On Wednesday, September 6, 2017 5:18:22 AM EDT Jan Kara wrote:
> > > Or is it that for CCrequirements you have to implement some deamon which
> > > will arbitrate access us
On Wed 06-09-17 10:35:32, Steve Grubb wrote:
> On Wednesday, September 6, 2017 5:18:22 AM EDT Jan Kara wrote:
> > On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> > > The fanotify interface allows user space daemons to make access
> > >
> > > control decisions. Under common criteria requirements, w
On 2017-09-06 10:20, Steve Grubb wrote:
> On Tuesday, September 5, 2017 11:24:49 PM EDT Richard Guy Briggs wrote:
> > On 2017-09-05 14:32, Steve Grubb wrote:
> > > The fanotify interface allows user space daemons to make access
> > >
> > > control decisions. Under common criteria requirements, we
Quoting Richard Guy Briggs (r...@redhat.com):
...
> > I believe we are going to need a container ID to container definition
> > (namespace, etc.) mapping mechanism regardless of if the container ID
> > is provided by userspace or a kernel generated serial number. This
> > mapping should be recorde
On Wednesday, September 6, 2017 7:11:48 AM EDT Amir Goldstein wrote:
> On Wed, Sep 6, 2017 at 12:18 PM, Jan Kara wrote:
> > On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> >> The fanotify interface allows user space daemons to make access
> >>
> >> control decisions. Under common criteria require
On Wed, Sep 6, 2017 at 9:20 AM, Vegard Nossum wrote:
> On 09/05/17 16:39, Paul Moore wrote:
>>
>> On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum
>> wrote:
>>>
>>> A few years ago, I suggested a feature dubbed "known exploit detection".
>>> This feature defines an interface that allows kernel devel
On Wednesday, September 6, 2017 5:18:22 AM EDT Jan Kara wrote:
> On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> > The fanotify interface allows user space daemons to make access
> >
> > control decisions. Under common criteria requirements, we need to
> > optionally record decisions based on pol
On Tuesday, September 5, 2017 11:24:49 PM EDT Richard Guy Briggs wrote:
> On 2017-09-05 14:32, Steve Grubb wrote:
> > The fanotify interface allows user space daemons to make access
> >
> > control decisions. Under common criteria requirements, we need to
> > optionally record decisions based on
Hi,
The examples found in the audit documentation mention that to work it is
assumed that no direct root login is allowed.
This very sensible and not a big problem except for console access.
What would be the best way to monitor what is done through this access ?
Would you recommend to forbid root
On 09/05/17 16:39, Paul Moore wrote:
On Mon, Sep 4, 2017 at 4:27 AM, Vegard Nossum wrote:
A few years ago, I suggested a feature dubbed "known exploit detection".
This feature defines an interface that allows kernel developers to add
a tripwire for somebody who tries to exploit a known security
On Wed, Sep 6, 2017 at 12:18 PM, Jan Kara wrote:
> On Tue 05-09-17 14:32:07, Steve Grubb wrote:
>> The fanotify interface allows user space daemons to make access
>> control decisions. Under common criteria requirements, we need to
>> optionally record decisions based on policy. This patch adds
A few years ago, I suggested a feature dubbed "known exploit detection".
This feature defines an interface that allows kernel developers to add
a tripwire for somebody who tries to exploit a known security hole in
older versions of the kernel. See [1] for an article and the original
discussion.
[1
On Tue 05-09-17 14:32:07, Steve Grubb wrote:
> The fanotify interface allows user space daemons to make access
> control decisions. Under common criteria requirements, we need to
> optionally record decisions based on policy. This patch adds a bit mask,
> FAN_AUDIT, that a user space daemon can
I got only following SYSCALL record in audit log for 'touch -t ' command, no CWD, no PATH recordtype=SYSCALL msg=audit(1503837757.149:266995): arch=c03e syscall=280 success=yes exit=0 a0=0 a1=0 a2=7fffbb26bb10 a3=0 items=0 ppid=101 pid=102 auid=1000 uid=0 gid=31 euid=0 suid=0 fsuid=0 egid=0 sgi
The exclude filter defaults to "never", ignoring the action. Make a note of
that to clarify the sense and intent of the filter.
Signed-off-by: Richard Guy Briggs
---
docs/audit.rules.7 |2 +-
docs/audit_add_rule_data.3 |2 +-
docs/auditctl.8|2 +-
3 files changed
On Tue, 5 Sep 2017, Richard Guy Briggs wrote:
> Factor out the case of privileged root from the function
> cap_bprm_set_creds() to make the latter easier to read and analyse.
>
> Suggested-by: Serge Hallyn
> Signed-off-by: Richard Guy Briggs
> Reviewed-by: Serge Hallyn
> ---
> security/common
17 matches
Mail list logo