Re: Problem with sockets and ACL

Javier Juan Martínez Cabezón <[email protected]>
Newsgroups gmane.linux.rsbac
Message-ID <[email protected]>
I have just seen that bind(IPC) is controlled by READ_WRITE_OPEN, did
you grant this?




On 27/03/12 16:07, Lorenzo Marcantonio wrote:
> I've just upgraded from 1.4.4 to 1.4.6 (using the 3.1.5 prepatched kernel)
> 
> Most of the things work, except an issue with sockets (both udevd and
> dbus-daemon trigger it, other programs like syslog-ng, dont);
> 
> udevd says: error initializing udevd socket and logs in this way:
> 
> Tue Mar 27 15:57:13 2012 :<6>0000000513|rsbac_adf_request(): request BIND, pid 30317, ppid 28618, prog_name udevd, prog_file /sbin/udevd, uid 0, audit uid 1000, target_type IPC, tid AnonUnix-ID 72455, attr sock_type, value DGRAM, result NOT_GRANTED by ACL
> 
> dbus-daemon instead goes this way: Failed to start message bus: Failed to bind socket "/tmp/dbus-4gAhH9BkiE": Operation not permitted
> 
> Tue Mar 27 15:58:23 2012 :<6>0000000514|rsbac_adf_request(): request BIND, pid 30557, ppid 30556, prog_name dbus-daemon, prog_file /usr/stow/dbus-1.4.1/bin/dbus-daemon, uid 1000, target_type IPC, tid AnonUnix-ID 66250, attr sock_type, value STREAM, result NOT_GRANTED by ACL
> 
> The strange thing is that I never touched IPC ACL and other socket based
> applications work... even syslog-ng (which uses /dev/log)
> 
> A strace of udev gives:
> 
> socket(PF_FILE, SOCK_DGRAM, 0)          = 5
> fcntl64(5, F_GETFL)                     = 0x2 (flags O_RDWR)
> fcntl64(5, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
> fcntl64(5, F_GETFD)                     = 0
> fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
> capget(0x20080522, 0, NULL)             = 0
> capget(0x20080522, 0, {CAP_SYS_ADMIN, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_SYS_ADMIN, 0}) = 0
> capget(0x20080522, 0, NULL)             = 0
> capget(0x20080522, 0, {CAP_SYS_ADMIN, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_SYS_ADMIN, 0}) = 0
> capset(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_ADMIN, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_SYS_ADMIN, 0}) = 0
> capget(0x20080522, 0, NULL)             = 0
> capget(0x20080522, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_ADMIN, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_SYS_ADMIN, 0}) = 0
> capset(0x20080522, 0, {CAP_DAC_OVERRIDE|CAP_NET_BIND_SERVICE|CAP_SYS_ADMIN, CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_BIND_SERVICE|CAP_NET_BROADCAST|CAP_NET_RAW|CAP_SYS_ADMIN, 0}) = 0
> stat64("/dev/log", {st_mode=S_IFSOCK|0666, st_size=0, ...}) = 0
> unlink("/dev/log")                      = 0
> bind(5, {sa_family=AF_FILE, path="/dev/log"}, 11) = 0
> 
> Instead a strace of udevd gives:
> 
> socket(PF_FILE, SOCK_DGRAM, 0)          = 4
> bind(4, {sa_family=AF_FILE, path=@"/org/kernel/udev/udevd"}, 25) = -1 EPERM (Operation not permitted)
> 
> ... I have no idea on what's happening ...
> 
> What I could try? are these governed by IPC :DEFAULT: or by FD /dev  ?
> 
> Thanks in advance for any help
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.