I am writing a build script which has some password protected files (keys). I need a way to prompt the user once for the password and then use this key across multiple scripts. These scripts do not live inside the same shell, and may spawn other windows via dbus. I can then send them commands, one of which must have access to the password.
I have this working already, but at a few points the passphrase is either used directly on a command-line (passed via dbus), or is put into a file (the name then passed to the other script). Both of these are less secure than I want*. The command-line ends up in a history which may be stored in a file, as well as appearing in the process list, and the second option stores in a file which can be read by somebody else.
Is there some standard way to create a temporary communications channel between two processes which could communicate the password and not be intercepted by another user on the system (including root)?
*Note: This is primarily an exercise to be fully secure. For my current project the temporary in-file storage of the password is okay.
Setting "root being all-powerful" aside, I would imagine that a Private DBus Connection would do the trick although the documentation I could find seems a little light on what exactly makes a private connection private.
However, the DBus Specification, more specifically, the Message Bus Specification subsection on eavesdropping says in part:
Receiving a unicast message whose DESTINATION indicates a different
recipient is called eavesdropping. On a message bus which acts as a
security boundary (like the standard system bus), the security policy
should usually prevent eavesdropping, since unicast messages are
normally kept private and may contain security-sensitive information.
So you may not even need to use private connections which incur more overhead costs. But on a risk/reward basis with security being paramount, that may be the more secure alternative for you. Hope that helps.
Related
The freeNAS_11.3 console allows a too simple password change:
When starting my freeNAS test server (freeNAS 11.3 Rel-p5 r325575),
I'm getting after a while of booting the option menu with 11 points
----
1) Configure Network Interfaces
...
7) Reset Root Password
...
11) Shut Down
----
With option 7) I'm immediately allowed to choose a new password,
without any question for the old password ...
In my opinion that can be a problem in situations where the freeNAS server
is running in a somehow "unsecure" environment.
Why there is (at least) no option to force
first the question for the old password
before changing to a new password?
From the Immutable Laws of IT Security:
Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore
What you have here is access to the machine directly. No remote interface of any good NAS system will allow a remote user to reset a password without authentication. However, it is assumed that if you have physical access(direct tty, session, etc. on the device - keyboard attached to the physical device) to the machine, you could do all sorts of thing to steal the data. Hence no tight security around the reset-passwort button.
Especially with a NAS, one could just grab the data drives and hook them into a different system to read them. To prevent this, encrypt your data either individually and/or all at once with something like Bitlocker. Then you have to type in your password on each startup, but that data will be encrypted at rest, meaning it'll take an attacker longer to get to your data.
What i have:
I am running a freeradius server fully configured of how i need it to be. Everything works just fine right now.
What i need:
I need the radius to put the devices in a seperate vlan before authentication and to run a vulnerability scan (nessus / openvas etc) on the devices in this vlan to check for software status ( antivirus etc. )
if the device passes the test the authentication should be done normaly.
if it fails it should be put into a third ( fourth if you count the unauth-vid ) vlan.
can someone tell me if this is doable in freeradius ?
thanks in advance for your answers
Yes. But this is a very broad question and is dependent on the networking equipment being used. I'll give you an overview of how I'd design such a system.
In general, you'll have an easier time if you can use the same DHCP server/IP range for your NAC and full access VLAN. That means you don't have to signal the higher networking layers in the client that there's been a state change, you can swap out VLANs behind the scenes to change what they can access.
You'd set up a database with an entry for each client. This doesn't have to be pre-populated, it could be populated during the first auth attempt. Part of each client entry would be a status field detailing when they last completed NAC.
You'd also need an accounting database, to store information about where each client is connected to the network.
If the client had never completed NAC checks before, you'd assign the client to the NAC VLAN, and signal your NAC processes to start interrogating it.
FreeRADIUS can act as both a RADIUS and DHCPv4 server, so you'd probably do signal the NAC process from the DHCPv4 side because then you'd know what IP the client received.
Binding the RADIUS and DHCPv4 sides can be done in a couple of ways. The most obvious is MAC, another common way is NAS/Port ID using the accounting table.
Once the NAC checks had completed, you'd have the NAC process write out a receipt in detail file format, and have that read back in by a detail file listener (there are examples of this in sites-available/ in the 'decoupled-accounting' virtual server files). When reading those entries back in, you'd change the state in the database, and send a CoA packet to the switch using information from the accounting database to identify the client. This would flip the VLAN and allow them to the standard set of networking resources.
I know this is very high level, documenting it properly would probably exceed StackOverflow's character limit. If you need more help with this, I suggest you research what I've described above and then start asking the RADIUS related questions on the FreeRADIUS user's mailing list https://freeradius.org/support/.
I want to check all the authorities and access levels of queues and channels in my MQ-manager and check if there is a client queue or channel with administrative access. In order to do that I used ./dmpmqaut command and I successfully dumped all the objects' authorities. However, I have two problems here:
1- There are a lot of objects in my Q-manager which has the entity of mqm and their authority is set to: almqi dlt chg dsp clr. So is this normal? I mean all I know is that the clients should not have mqm entity name and the authorities are not restricted at all here. Am I right?
2- I want to check all the channels and queues MCAUSER like what I can see in MQ-Explorer on windows. Is there any way that I can check it in Linux machine?
Whenever an MQ object is created, the user who created it (or that user's primary group in non-Windows Distributed platforms) is granted all rights to the object. In practice, this usually means that the mqm group is visible on every object when you do an auths dump. On windows, this is often adminID#domain in addition to mqm.
On Linux you can do...
echo "dis chl(*) mcauser | runmqsc [qmgrname]
...from the command line to see what the MCAUSER is on the channels. You can also see this using MQ Explorer.
The defined MCAUSER for all inbound channels should be one that blocks all access. I used to recommend nobody but since this is potentially a valid ID on some systems, I now recommend *nobody. Note that by "inbound channels" I mean those of type RCVR, RQSTR, CLUSRCVR, and SVRCONN. By "all" I mean channels named SYSTEM.AUTO.*, SYSTEM.DEF.*, and any that you define yourself.
Make sure that an exit or a CHLAUTH rule maps the MCAUSER to the expected value when the connection request is authenticated. The CHLAUTH rules are available on any version of MQ from 7.1 on up. This mapping ensures that only an authenticated user or partner QMgr can connect.
If authorizations (setmqaut or SET AUTHREC commands) are defined without also defining the CHLAUTH rules or setting up a security exit, the effect is worse security, not better. The reason being that legitimate users will appear to have restrictions placed on their connection but malicious users will be able to easily spoof an administrative user ID.
Please see the basic MQ Security Hardening slides at http://t-rob./net/links for more on this topic.
I have a public computer that is used in an ATM sort of fashion. When a certain action occurs (person inserts money), the program I've written on the computer sends a request to a trusted server which does a very critical task (transfers money).
I'm wondering, since I have to communicate to a server to start the critical task, the credentials to communicate with it are stored on this public computer. How do I prevent hackers from obtaining this information and running the critical task with their own parameters?
HSM (Hardware Security Modules) are designed to store keys safely:
A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.
HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Each module contains one or more secure cryptoprocessor chips to prevent tampering and bus probing.
Impossible in general
If your user has access to this PC, they can easily insert fake money. Your model is doomed.
Minimize attack surface
This PC ought to have unique token (a permanent cookie is enough), and sever will refuse a request without a valid cookie. Server maintains database of device types, and this ATM-PC is only allowed certain operations (deposit money up to NNN units). Ideally it is also rate-limited (at most once per 3 seconds).
SO_PEERCRED is simple way to get pid/uid/gid of connected AF_UNIX stream socket, SCM_CREDENTIALS is more or less the same, but more complex (various ancillary messages). Links to example showing both ways.
Why there are two ways to get more or less the same information?
Why the more comfortable SO_PEERCRED is not listed in unix(7) manpage?
Which is use more in real-life applicatins?
What should I use?
If I understand correctly, there is a subtle difference between the two. SO_PEERCRED retrieves the credentials of the peer process, without requiring any interaction from the peer process. In contrast, SCM_CREDENTIALS is a mechanism to send / receive credentials of the peer process, which are then checked by the kernel. This subtle difference may matter when a process is running as UID 0. SCM_CREDENTIALS allows a process running as UID 0, to declare itself less privileged (e.g., UID 50), whereas this would not be possible with SO_PEERCRED.
See above. I guess using SCM_CREDENTIALS is encouraged and SO_PEERCRED is only supported for compatibility.
The dbus daemon seems to use SO_PEERCRED and getpeereid(). I think it is best to copy their code in order to portably get the credentials.
http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c?id=edaa6fe253782dda959d78396b43e9fd71ea77e3
SO_PEERCRED returns the socket peer's credentials. SCM_CREDENTIALS allows you to pass any credentials which you have privilege over. This is particularly valuable because the kernel will translate the ids, so a task in one pid namespace can send a pid to process in another namespace, and be assured that the received pid will refer to the same process it intended.
If you want the peer's credential then use SO_PEERCRED. SCM_CREDENTIAL is a credential which the caller specified (which it did have to have privilege over), not necessarily the peer's.