I have an issue in a yocto based embedded linux system. I have tracked it down to an interaction between dbus and SELinux, and using dbus-monitor I can see the following error:
error time=1621869986.514891 sender=org.freedesktop.DBus -> destination=:1.4 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=69729
string "An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_return", sender=":1.4" (uid=0 pid=905 comm="/usr/sbin/NetworkManager --no-daemon " label="system_u:system_r:NetworkManager_t:s0") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.6390" (uid=0 pid=14426 comm="/opt/metix-embedded/metix-wg-ui " label="system_u:system_r:init_t:s0")"
However, there is no 'AVC denied' error in the audit log, so I cannot use audit2allow to determine an SELinux rule to allow the interaction.
How can I work out the SELinux rule I need from the dbus-monitor error?
Further research shows that dbus itself is an SELinux aware application. It is checking the SELinux configuration, and taking enforcement actions within dbus itself. This accounts for why the denials from dbus do not appear in the audit log, even when silent denials are turned off.
My particular issue was solved by adding some allow rules for 'send_msg' as follows:
allow init_t NetworkManager_t:dbus send_msg;
allow NetworkManager_t init_t:dbus send_msg;
Note that the 'init_t' and 'NetworkManager_t' types are derived from the dbus-monitor error.
Further information:
https://hub.packtpub.com/handling-selinux-aware-applications/
https://blog.siphos.be/2014/06/d-bus-and-selinux/
https://relativkreativ.at/articles/how-to-compile-a-selinux-policy-package
Related
I am currently experiencing the problem that my freeradius installation with the kerberos5 module does not like my rcache. It spits this error when authenticating.
ERROR: (0) krb5: Error verifying credentials (-1765328174): Generic preauthentication failure
According to Kemptechnologies this error code means the rcache format is not supported.
-1765328174
KRB5_RCACHE_BADVNO
Unsupported replay cache format version number
I tried to disable rcache by using the information provided by MIT.
http://web.mit.edu/kerberos/krb5-devel/doc/basic/rcache_def.html
Setting KRB5RCACHETYPE to none to disable it, setting it to dfl and setting the KRB5RCACHEDIR to /tmp but freeradius seems to not like any option.
Can anyone tell me how i have to format the rcache so that freeradius is able to read it?
I am trying to write modsecurity rule exclusions and cant seem to get ctl:ruleRemoveTargetById to work as per the reference manual.
My server is running Debian 9 with apache2 2.4.25-3+deb9 I have tried following the reference manual on github and tried emulating the sample rules in the file >REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf. I have written a simple rule to fire on certain arguments and then tried excluding it, but it wont exclude the rule based on the arguments. I can see both the rule id and the rule exclusion id in the logs.
I have, arbitrarily, put the below rule in REQUEST-905-COMMON-EXCEPTIONS.conf
SecRule ARGS "#rx propfind" "id:905999,phase:2,log,msg:'test msg delete rule'"
This fires as it should. There is an argument named <?xml version that contains the pattern "propfind" in my nextcloud settings page, which I am using for testing.
I have also written an exclusion and put it into REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
SecRule ARGS_NAMES "#rx <\?xml\sversion" "phase:2,log,id:1030,ctl:ruleRemoveTargetById=905999;ARGS:/<\?xml\sversion/"
This rule triggers as expected but does not prevent rule 905999 from firing on argument named <?xml version
I have simplified the rules to the two below and it works as expected; when I enter example.com/?test=trigger I see rule 905999 in the log, but if I send example.com/?testarg=trigger I only see the exclusion rule 1030 as expected.
SecRule ARGS "#rx trigger" "id:905999,phase:2,log,msg:'test msg delete rule'"
SecRule ARGS_NAMES "#rx testarg" "phase:2,log,id:1030,ctl:ruleRemoveTargetById=905999;ARGS:testarg"
When I open the nextcloud settings tab the HTTP request contains
<?xml version="1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:resourcetype/></d:prop></d:propfind>
which Modsec interprets as the argument name <?xml version, containing the value "1.0"?><d:propfind xmlns:d="DAV:"><d:prop><d:resourcetype/></d:prop></d:propfind>
I would expect my rule 1030 to stop 905999 from firing, but i still see both rules in the log. I am assuming it is because of the space between "xml" and "version" but cant figure out how to exclude the target.
For some reason the regex in ctl:ruleRemoveTargetById=905999;ARGS:/<\?xml\sversion/ did not work. Using SecRuleUpdateTargetById 905999 "!ARGS:/<\?xml\sversion" and placing it into RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf to update the rule targets after they are loaded works as desired.
I followed this article to enable FTRACE
https://lwn.net/Articles/365835/
to test a realtime system, my system uses arm cortexa15 (Description: https://mp.renesas.com/en-us/rzg/marketplace/board/RZGB000003.html)
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
But, it didn't work, caused the system hang-up when starting kernel.
Even referred How to Enable or configure ftrace module
I would like to test latency in the realtime system with cyclictest (option -b to trigger FTRACER)
cyclictest -a -t -n -p99 -f -b100
It generated dump message:
INFO: debugfs mountpoint: /sys/kernel/debug/tracing/
WARN: tracing_enabled or tracing_on not found
debug fs not mounted, TRACERs not configured?
could not set ftrace_enabled to 0
FATAL: Can't open /sys/kernel/debug/tracing/available_tracers for reading
I repeated a next step to enable a group of tracer configs:
CONFIG_FTRACE=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FUNCTION_TRACER=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_TRACEPOINT_BENCHMARK=y
CONFIG_BACKTRACE_SELF_TEST=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_LL=y
The result still was the same. Kernel hung and didn't show anything.
Anyone who deal with realtime system and Ftrace can help ? Thanks.
I resolve my problem. Below is a part of my defconfig file.
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_TRACEPOINTS=y
CONFIG_STACKTRACE=y
CONFIG_NOP_TRACER=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_GENERIC_TRACER=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
CONFIG_STACK_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_FTRACE_MCOUNT_RECORD=y
After enabling Ftrace tool, the culprit can then be found in the trace output at /sys/kernel/debug/tracing/trace. The kernel function that was executed just before a latency of more than 100 microseconds was detected is marked with an exclamation mark.
I have been working with HFC SDK for Node.js and it used to work, but since last night I am having some problems.
When running helloblockchain.js only few times works, most time I get this error when it tries to enroll a new user:
E0113 11:56:05.983919636 5288 handshake.c:128] Security handshake failed: {"created":"#1484304965.983872199","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484304965.983866102","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
Error: Failed to register and enroll JohnDoe: Error
Other times, the enroll works and the failure appears deploying the chaincode:
Enrolled and registered JohnDoe successfully
Deploying chaincode ...
E0113 12:14:27.341527043 5455 handshake.c:128] Security handshake failed: {"created":"#1484306067.341430168","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484306067.341421859","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
Failed to deploy chaincode: request={"fcn":"init","args":["a","100","b","200"],"chaincodePath":"chaincode","certificatePath":"/certs/peer/cert.pem"}, error={"error":{"code":14,"metadata":{"_internal_repr":{}}},"msg":"Error"}
Or:
Enrolled and registered JohnDoe successfully
Deploying chaincode ...
E0113 12:15:27.448867739 5483 handshake.c:128] Security handshake failed: {"created":"#1484306127.448692244","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484306127.448668047","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
events.js:160
throw er; // Unhandled 'error' event
^
Error
at ClientDuplexStream._emitStatusIfDone (/usr/lib/node_modules/hfc/node_modules/grpc/src/node/src/client.js:189:19)
at ClientDuplexStream._readsDone (/usr/lib/node_modules/hfc/node_modules/grpc/src/node/src/client.js:158:8)
at readCallback (/usr/lib/node_modules/hfc/node_modules/grpc/src/node/src/client.js:217:12)
E0113 12:15:27.563487641 5483 handshake.c:128] Security handshake failed: {"created":"#1484306127.563437122","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484306127.563429661","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
This code worked yesterday, so I don't know what could be happening.
Does anybody know how can I fix it?
Thanks,
Javier.
ibm-bluemix
blockchain
These types of intermittent issues are usually related to GRPC. An initial suggestion is to ensure that you are using at least GRPC version 1.0.0.
If you are using a Mac, then the maximum number of open file descriptors should be checked (using ulimit -n). Sometimes this is initially set to a low value such as 256, so increasing the value could help.
There are a couple of GRPC issues with similar symptoms.
https://github.com/grpc/grpc/issues/8732
https://github.com/grpc/grpc/issues/8839
https://github.com/grpc/grpc/issues/8382
There is a grpc.initial_reconnect_backoff_ms property that is mentioned in some of these issues. Increasing the value past the 1000 ms level might help reduce the frequency of issues. Below are instructions for how the helloblockchain.js file can be modified to set this property to a higher value.
Open the helloblockchain.js file in the Hyperledger Fabric Client example and find the enrollAndRegisterUsers function.
Add “grpc.initial_reconnect_backoff_ms": 5000 to the setMemberServicesUrl call.
chain.setMemberServicesUrl(ca_url, {
pem: cert, "grpc.initial_reconnect_backoff_ms": 5000
});
Add “grpc.initial_reconnect_backoff_ms": 5000 to the addPeer call.
chain.addPeer("grpcs://" + peers[i].discovery_host + ":" + peers[i].discovery_port,
{pem: cert, "grpc.initial_reconnect_backoff_ms": 5000
});
Note that setting the grpc.initial_reconnect_backoff_ms property may reduce the frequency of issues, but it will not necessarily eliminate all issues.
The connection to the eventhub that is made in the helloblockchain.js file can also be a factor. There is an earlier version of the Hyperledger Fabric Client that does not utilize the eventhub. This earlier version could be tried to determine if this makes a difference. After running git clone https://github.com/IBM-Blockchain/SDK-Demo.git, run git checkout b7d5195 to use this prior level. Before running node helloblockchain.js from a Node.js command window, the git status command can be used to check the code level that is being used.
I have installed Gnumeric in CentOS 6.5, then use ssconvert command to convert .xls/.xlsx file to CSV, but I still get the following error:
$ ssconvert
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you
have stale NFS locks due to a system crash. See
http://projects.gnome.org/gconf/ for information. (Details - 1: Not
running within active session)
GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you
have stale NFS locks due to a system crash. See
http://projects.gnome.org/gconf/ for information. (Details - 1: Not
running within active session)
** (ssconvert:5725): WARNING **: Configured default font 'Sans 10.000000' not available, trying fallback...
** (ssconvert:5725): WARNING **: Fallback font 'Sans 10.000000' not available, trying 'fixed'...
** (ssconvert:5725): WARNING **: Even 'fixed 10' failed ?? We're going to exit now,there is something wrong with your font
configuration
Can you help me?
As this is an old question, the answer is in case someone will get the same error (like me today on CentOS 6.8), you missed to install the Sans font:
yum install gnu-free-sans-fonts
For docker alpine images this might help:
RUN apk add --update \
msttcorefonts-installer fontconfig \
ttf-opensans