Re: [Vserver] audit interface
Quoting Gregory (Grisha) Trubetskoy ([EMAIL PROTECTED]): On Thu, 14 Jul 2005, Enrico Scholz wrote: [EMAIL PROTECTED] (Enrico Scholz) writes: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. Quick workaround is to add '^29' to the 'bcapabilities' of the corresponding vserver. Next util-vserver version will probably implicate this with the '--secure' option (after I decided how to deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict). This didn't work for me (just to make su - work), it seems that I needed ^30 (CAP_AUDIT_CONTROL). Does anyone here know what the security implication of this is? We don't run auditd. IIRC I originally added this capability... It's too coarse-grained for my liking, but only applicable to audit. It allows your process to change its loginuid, which you see reported in the audit msgs, but which is not used for any authentication. (same bit allows adding/del'ing/listing audit rules, iirc) For vserver, loginuid should probably always be reported along with the vserver id, I guess... -serge ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
On Mon, Nov 14, 2005 at 06:54:23AM -0600, Serge E. Hallyn wrote: Quoting Gregory (Grisha) Trubetskoy ([EMAIL PROTECTED]): On Thu, 14 Jul 2005, Enrico Scholz wrote: [EMAIL PROTECTED] (Enrico Scholz) writes: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. Quick workaround is to add '^29' to the 'bcapabilities' of the corresponding vserver. Next util-vserver version will probably implicate this with the '--secure' option (after I decided how to deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict). This didn't work for me (just to make su - work), it seems that I needed ^30 (CAP_AUDIT_CONTROL). Does anyone here know what the security implication of this is? We don't run auditd. IIRC I originally added this capability... It's too coarse-grained for my liking, but only applicable to audit. It allows your process to change its loginuid, which you see reported in the audit msgs, but which is not used for any authentication. (same bit allows adding/del'ing/listing audit rules, iirc) ah, you are the one who is to blame for this mess ... :) For vserver, loginuid should probably always be reported along with the vserver id, I guess... patches to virtualize the loginuid are welcome, as well as an explanation why it is require at all (especially from userspace) TIA, Herbert -serge ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
Quoting Herbert Poetzl ([EMAIL PROTECTED]): ah, you are the one who is to blame for this mess ... :) Well, I wanted to use lsm hooks, not capabilities... For vserver, loginuid should probably always be reported along with the vserver id, I guess... patches to virtualize the loginuid are welcome, as well I assume the final consumer of the audit logs is the owner of the physical machine, not each vserver owner? I'm wondering whether just adding the vserver id to each audit message, and adding a capability to distinguish setting loginuid from the other actions currently controlled by CAP_AUDIT_CONTROL would be sufficient... Then only the real owner can add and delete rules, each vserver can set loginuids, but the real owner will always see at least the vserver id responsible for an event. as an explanation why it is require at all (especially from userspace) Well, only the latter right now: The loginuid is supposed to be the first uid you log in as. Further setuids should not change the loginuid, in order to ensure that audit messages are accounted to the original login account. So you need to change the loginuid through PAM (so that admin can decide which programs are allowed to determine loginuid), and need the capability to make sure only privileged users can do so. Or, short answer: CAPP and LSPP. -serge ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
Thanks! Just for documentation in case anyone gets stuck trying to fix this: It looks like older FC4 pam will work with ^30, and newer (pam-0.79-9.6) requires *both* ^29 and ^30. (Doesn't matter, BTW, whether you have pam_loginuid.so in your config, it looks like it is patched to use audit regardless). Grisha On Mon, 14 Nov 2005, Serge E. Hallyn wrote: Quoting Gregory (Grisha) Trubetskoy ([EMAIL PROTECTED]): On Thu, 14 Jul 2005, Enrico Scholz wrote: [EMAIL PROTECTED] (Enrico Scholz) writes: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. Quick workaround is to add '^29' to the 'bcapabilities' of the corresponding vserver. Next util-vserver version will probably implicate this with the '--secure' option (after I decided how to deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict). This didn't work for me (just to make su - work), it seems that I needed ^30 (CAP_AUDIT_CONTROL). Does anyone here know what the security implication of this is? We don't run auditd. IIRC I originally added this capability... It's too coarse-grained for my liking, but only applicable to audit. It allows your process to change its loginuid, which you see reported in the audit msgs, but which is not used for any authentication. (same bit allows adding/del'ing/listing audit rules, iirc) For vserver, loginuid should probably always be reported along with the vserver id, I guess... -serge ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
On Thu, 14 Jul 2005, Enrico Scholz wrote: [EMAIL PROTECTED] (Enrico Scholz) writes: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. Quick workaround is to add '^29' to the 'bcapabilities' of the corresponding vserver. Next util-vserver version will probably implicate this with the '--secure' option (after I decided how to deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict). This didn't work for me (just to make su - work), it seems that I needed ^30 (CAP_AUDIT_CONTROL). Does anyone here know what the security implication of this is? We don't run auditd. Grisha ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
[EMAIL PROTECTED] (Herbert Poetzl) writes: it seems to be impossible to use the audit (CONFIG_AUDIT) interface of the kernel within a vserver: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. hmm, does anybody know why pam would want to do syscall auditing in the first place? I'm a little lost here actually ... ah, looks like redhat is patching again ... http://people.redhat.com/sgrubb/audit/pam-0.78-loginuid.patch so I guess it's fine to remove pam_loginuid.so for now until the auditing interface is virtualized ... Ok, as expected, the NETLINK problem can be solved by giving CAP_AUDIT_WRITE permissions by default. Next problem is a | [pid 10153] open(/proc/self/loginuid, O_WRONLY|O_TRUNC|O_NOFOLLOW) = -1 EPERM (Operation not permitted) Hiding /proc/self/loginuid (so that open(2) returns with -ENOENT) seems to make newer pam_loginuid happy[1]. As this can not be done with procfs-security, would it be possible to hide the loginuid entry statically for context!=0? (I guess, making it writable is more complicated than hiding it). Enrico Footnotes: [1] http://cvs.fedora.redhat.com/viewcvs/rpms/pam/FC-4/pam-0.79-cleanup-redhat.patch?r1=1.3r2=1.4 -- /\ \ /ASCII Ribbon Campaign X against HTML email vCards / \ http://www.harley.com/turn-off-html/ ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
On Sun, Jul 17, 2005 at 01:52:49PM +0200, Enrico Scholz wrote: [EMAIL PROTECTED] (Herbert Poetzl) writes: it seems to be impossible to use the audit (CONFIG_AUDIT) interface of the kernel within a vserver: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. hmm, does anybody know why pam would want to do syscall auditing in the first place? I'm a little lost here actually ... ah, looks like redhat is patching again ... http://people.redhat.com/sgrubb/audit/pam-0.78-loginuid.patch so I guess it's fine to remove pam_loginuid.so for now until the auditing interface is virtualized ... Ok, as expected, the NETLINK problem can be solved by giving CAP_AUDIT_WRITE permissions by default. Next problem is a | [pid 10153] open(/proc/self/loginuid, O_WRONLY|O_TRUNC|O_NOFOLLOW) = -1 EPERM (Operation not permitted) Hiding /proc/self/loginuid (so that open(2) returns with -ENOENT) seems to make newer pam_loginuid happy[1]. As this can not be done with procfs-security, would it be possible to hide the loginuid entry statically for context!=0? (I guess, making it writable is more complicated than hiding it). I'd suggest we disable the auditing framework for now (if the pam module is happy with that?) and try to virtualize the auditing ASAP ... do you have/know any good test tools except the FC4 pam plugin? could you try if disabling the audit framework does indeed make it work? if everything else fails, we can remove that entry (or whatever entry is used to detect the auditing) TIA, Herbert Enrico Footnotes: [1] http://cvs.fedora.redhat.com/viewcvs/rpms/pam/FC-4/pam-0.79-cleanup-redhat.patch?r1=1.3r2=1.4 -- /\ \ /ASCII Ribbon Campaign X against HTML email vCards / \ http://www.harley.com/turn-off-html/ ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
[Vserver] audit interface
Hello,
it seems to be impossible to use the audit (CONFIG_AUDIT) interface
of the kernel within a vserver:
| # auditctl -m 'foo'
| Error sending user message request (Operation not permitted)
The generated syscalls are:
| socket(PF_NETLINK, SOCK_RAW, 9) = 3
| fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
| sendto(3, \24\0\0\0\355\3\5\0\1\0\0\0\0\0\0\0foo\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
| select(4, [3], NULL, NULL, {0, 10}) = 1 (in [3], left {0, 10})
| recvfrom(3, $\0\0\0\2\0\0\0\1\0\0\0!e\0\0\377\377\377\377\24\0\0\0...,
8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=},
[12]) = 36
| write(2, Error sending user message reque..., 60Error sending user message
request (Operation not permitted)) = 60
This gives problems on Fedora Core 4 as recent pam upgrade is
using this functionality and most actions (su, cron) will fail
therefore.
I see two ways to solve the problem:
1. allow this kind of communication within a context
2. make CONFIG_AUDIT conflict with CONFIG_VSERVER and hope that
libaudit is clever enough to ignore this error (untested)
(I do not know the security implications of 1. and have not
tested 2.)
Problem was seen on 2.6.12.2-vs2.0-rc5 + remap patch.
Enrico
pgptjlKWpNF4I.pgp
Description: PGP signature
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
[EMAIL PROTECTED] (Enrico Scholz) writes: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. Quick workaround is to add '^29' to the 'bcapabilities' of the corresponding vserver. Next util-vserver version will probably implicate this with the '--secure' option (after I decided how to deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict). Enrico pgpDbxbFH1pML.pgp Description: PGP signature ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
On Thu, Jul 14, 2005 at 05:32:40PM +0200, Enrico Scholz wrote: [EMAIL PROTECTED] (Enrico Scholz) writes: | # auditctl -m 'foo' | Error sending user message request (Operation not permitted) ... This gives problems on Fedora Core 4 as recent pam upgrade is using this functionality and most actions (su, cron) will fail therefore. hmm, will look into it ... Quick workaround is to add '^29' to the 'bcapabilities' of the corresponding vserver. Next util-vserver version will probably implicate this with the '--secure' option (after I decided how to deal with the CAP_QUOTACTL vs. CAP_AUDIT_WRITE conflict). #define CAP_AUDIT_WRITE 29 #define CAP_AUDIT_CONTROL30 quota was moved into the CCAPS a long? time ago (at least for 2.6/2.0 so nothing to deal with) #define CAP_CONTEXT 31 is the only remaining capability ... best, Herbert Enrico ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver ___ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
Re: [Vserver] audit interface
On Fri, Jul 15, 2005 at 12:50:51AM +0200, Herbert Poetzl wrote:
On Thu, Jul 14, 2005 at 03:21:36PM +0200, Enrico Scholz wrote:
Hello,
it seems to be impossible to use the audit (CONFIG_AUDIT) interface
of the kernel within a vserver:
| # auditctl -m 'foo'
| Error sending user message request (Operation not permitted)
The generated syscalls are:
| socket(PF_NETLINK, SOCK_RAW, 9) = 3
| fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
| sendto(3, \24\0\0\0\355\3\5\0\1\0\0\0\0\0\0\0foo\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
| select(4, [3], NULL, NULL, {0, 10}) = 1 (in [3], left {0, 10})
| recvfrom(3, $\0\0\0\2\0\0\0\1\0\0\0!e\0\0\377\377\377\377\24\0\0\0...,
8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0,
groups=}, [12]) = 36
| write(2, Error sending user message reque..., 60Error sending user
message request (Operation not permitted)) = 60
This gives problems on Fedora Core 4 as recent pam upgrade is
using this functionality and most actions (su, cron) will fail
therefore.
hmm, does anybody know why pam would want to do syscall
auditing in the first place? I'm a little lost here
actually ...
ah, looks like redhat is patching again ...
http://people.redhat.com/sgrubb/audit/pam-0.78-loginuid.patch
so I guess it's fine to remove pam_loginuid.so for now
until the auditing interface is virtualized ...
best,
Herbert
TIA,
Herbert
I see two ways to solve the problem:
1. allow this kind of communication within a context
2. make CONFIG_AUDIT conflict with CONFIG_VSERVER and hope that
libaudit is clever enough to ignore this error (untested)
(I do not know the security implications of 1. and have not
tested 2.)
Problem was seen on 2.6.12.2-vs2.0-rc5 + remap patch.
Enrico
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
___
Vserver mailing list
Vserver@list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver
