We now have a Publisher to report on disk events and its metadata,
using the DiskArbitration framework on OS X. Currently disk appearance
and disappearance events are published for both physical and
virtual disks (DMG files). On an event trigger, disk properties are
parsed and that metadata is reported along with the action.
The Subscriber subscribes to virtual disk events currently.
This closes#1103.
`int osquery::filter(const struct dirent*)` seemed like a pretty generic
symbol to have in our symbol table, so I changed it to
`int msrScandirFilter(const struct dirent*)`
This infomation is primarily related to the performance of processor
cores. The information given constitutes only a small portion of
the information in the model specific register, but this table
has been designed so that more information may easily be added.
The table requires osquery be run as the root, and that the msr
kernel module is loaded. The table reads the msr data from /dev
1. Example queries will run with an (optional) integration test.
2. Fix bad accesses with OS X package BOMs
3. Move spec files from ./osquery/tables/specs to ./specs
4. Remove server parsers (netlib) from client builds.
This change allows QueryContext constraints to be checked for based on
operator type. This makes checks for the existence of an equality
operator allow enumeration.
Example:
if (context.constraints["pid"].exists(EQUALS)) {
pids = context.constraints["pid"].getAll(EQUALS);
} else {
osquery::procProcesses(pids);
}
This implements the following tables on FreeBSD:
process_envs
process_memory_map
process_open_files
process_open_sockets
processes
All the heavy lifting is done with libprocstat(3). All the tables follow
the same general principle. Use the common function, getProcesses() in
procstat.cpp, to get the processes and then generate the rows for each
process returned. There is also a procstatCleanup() function commonly
used across all the tables.
The one thing I am not able to test is the process_open_sockets table on
an IPv6 machine.
The user_groups table represents the association between user ids and group ids.
Darwin Issue:
Issues arise in darwin systems with users that are members of many groups due
to a bug in Apple's implementation of getgrouplist. If the number of groups a
user is a member of is greater than 64 a truncated association table may
be returned.
Previously this only existed in the yara table, but it now exists in the
yara config parser land, which will compile signature groups upon
update. Now your signature groups can reference signature files using
paths relative to /var/osquery.
This was causing a crash when executing a query using the yara table
from the command line, because YARA was never initialized properly, so
the thread index was whatever was left on the stack. Eventually YARA
would attempt to set a rule that matches using this thread index and
would explode in flames.
Fix it by moving the initialization to a place that is always called.
1. Minor refactoring.
- Generate one row per sigfile or sig_group.
- While here, when a signature file fails to compile, VLOG() it.
2. Bring in a couple of YARA tests.
Write a couple of tests for YARA functionality. Right now the only tests
make sure rules are compiled properly and that rules match where they
should and don't match where they shouldn't.
3. Allow sigfiles to be relative to /var/osquery.
- Also, only create a row if scanning happened.
4. Add pattern support to yara table.
- Also, optimize things so that rules are only compiled once.
1. Rename yara_matches to yara_events.
2. Add support for Config::getParser().
- This returns a ConfigPluginRef, which is the ConfigParser for the
given key.
- Being able to get the parser is useful because the
YARAConfigParserPlugin uses it to store the compiled rules as an
attribute.
3. Finish rename and use ConfigParserPlugin.
- Finish the table rename to yara_events.
- Use the new ConfigParserPlugin interface to parse the YARA
configuration. The file_paths and signatures are stored in the
ConfigParserPlugin named "yara" under the key "yara". The rules are
compiled and stored as a private attribute of the same
ConfigParserPlugin object.
Here is an example config using this new structure:
{
// Description of the YARA feature.
"yara": {
"signatures": {
// Each key is an arbitrary group name to give the signatures listed
"sig_group_1": [ "/Users/wxs/foo.sig", "/Users/wxs//bar.sig" ],
"sig_group_2": [ "/Users/wxs/baz.sig" ]
},
"file_paths": {
// Each key is a key from file_paths
// The value is a list of signature groups to run when an event fires
// These will be watched for and scanned when the event framework
// fire off an event to yara_events table
"system_binaries": [ "sig_group_1" ],
"tmp": [ "sig_group_1", "sig_group_2" ]
}
},
// Paths to watch for filesystem events
"file_paths": {
"system_binaries": [ "/usr/bin/%", "/usr/sbin/%" ],
"tmp": [ "/Users/wxs/tmp/%%" ]
}
}
- Currently the signature file must be an absolute path.
3. Move common YARA code to yara_utils.
- In preparation for the yara table (different from yara_events) I'm
moving the common YARA code into a separate place which is shared
between the two tables.
4. Add yara table.
- This allows you to do things like:
```sql
select * from yara where path="/bin/ls" and sigfile="/tmp/foo.sig";
select * from yara where path="/bin/ls" and sig_group="sig_group_1";
```
- The latter will use the signature grouping from the config.
5. Check for keys not existing.
moved disk_ecryption table spec to crossplatform
link libcryptsetup
implemented get cipher type and cipher_mode:
more idiomatic c++11
no need to explicitly call std::string constructor to convert char * to std::string
update cryptsetup sources for centos
add function prototype for older libcryptsetup which is in centos6
ifdef check for centos6 which uses older libcryptsetup
remove forward declared functions defined in libcryptsetup, stylistic changes
