I am not understanding about defaultSession,ProgrammingSession,extendedDiagnosticSession in UDS protocol.
How can we go from one session to another session? please help me.Thank you.
default session = ECU is in normal operation state, but it usualy response only to limited set of diagnostic requests. From this state you can usually switch into:
extended session to perform some diagnostic services, to talk with ECU (Read/Write values, start/stop routines etc.) Here you expect that ECU give a more or less timely response on your requests. therefore you can also switch between sessions
programming session to flash ECU memory, to update ECU SW. While updating ECU usually do not answer on diagnostic requests. Therefore it's not usual to switch from programming session into extended session or even into default session as this switch is a diagnostic request from tester. At the end of an update ECU can perform some memory checks and it will do a reset. When update was successful it will restart in default session.
There can be also other diagnostic sessions for example: dealer session, OEM session...
Where is the problem? Since you are using CANoe, you can simply switch the session with the "Session Control" tool, which is in the ribbon menu "Diagnostics & XCP". For more info take a look at the chapter "Diagnostic Session Control" of the help.
If the ECU is protected you need to configure the seed & key DLL file and configuration. For more info look at "Seed & Key DLL / Security Access".
For an example take a look at the "UDSSystem" demo.
Related
The Service Bus documentation states that "the At-Most-Once semantic can be supported by using session state to store the application state and by using transactions to atomically receive messages and update the session state." "Session" here appears to refer to Service Bus' messaging sessions, which include the ability to store arbitrary state. This mechanism lets you enroll state updates in transactions along with operations on messages.
I see how this can be used to reliably maintain the state of an application that is using message sessions. If you can update application state and complete a message in the same transaction, a properly-implemented app could potentially die anywhere in execution, and on resume would be guaranteed to inherit a state that results in successful, in-order continued session processing (sample code is here, though strangely it doesn't actually use transactions, although I see how it could and what that would accomplish).
What I don't see is how any of this translates to "at-most-once" delivery. Nothing about Service Bus, including updates to session state, can be enrolled in a distributed transaction. So what exactly does "at-most-once" mean, and what does it accomplish? And what distinguishing feature of Service Bus allows it to support "at-most-once" delivery when Azure Storage queues do not?
After looking at your post and reading through the doc, I realized it wasn't really explaining at-most-once.
So I reached out to the concerned team and confirmed that it is indeed incorrect. A PR has been raised to fix the doc accordingly.
Instead, sessions and transactions together provide a higher level of consistency which is commonly referred to as exactly-once processing (which can't really be achieved just by the message broker itself but along with a receiver capable of deduplication).
PS: at-most-once is indeed possible by simply using the ReceiveAndDelete mode
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 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.
The User Experience guidelines state that the sender app should resume the session after it is killed and restarted. Specifically it says "If the sender app gets killed, it should have the Cast session context stored and be able to resume the session from that context when the sender app is restarted." Few questions...
What does "Cast session context" mean in this situation? Is this some object or objects in the Cast API that can be persisted then restored OR or something more general?
In order for this to happen and not interfere with another app that may have cast to the same device while the original app was dead, the new instance of the original app must be able to query if a given device is running the original app's receiver, some other receiver or no receiver. How is this accomplished?
If the app is to resume to the same Chromecast device then some identifier for the device must be saved as the app is being destroyed. Is the getDeviceId in CastDevice the correct thing to store?
The preview SDK has some shortcomings that prevent you from a complete implementation of this feature. When the official SDK becomes available, this will be fully addressed.
FYI, in order to reconnect your previous "state", you need to persist certain information so next time you can identify the device/route and the session that you had initiated before. Unfortunately, as I mentioned above, the APIs that you would need for a full and clean recovery process are not completely there in the preview SDK, so you can ignore this aspect of the UX Guideline till the official release provides all the needed pieces for you.
I'm writing a server application and its client counterpart that both use Netty for the network layer. I find myself facing typical safety concerns about sending a password from a client to the server so I decided SSL was the safest way of doing this.
I know of the securechat example and will use this to modify my pipelines accordingly. However, I would also like to disable SSL after password transmission and acknowledge to save a few precious CPU cycles on server side, which may be busy with many other clients. The ChannelPipeline documentation states that:
"Once attached, the coupling between the channel and the pipeline is permanent; the channel cannot attach another pipeline to it nor detach the current pipeline from it."
The idea is then to not change the pipeline on-the-fly, which is prohibited, but to somehow tell the SslHandler in the pipeline that it should stop encrypting messages at some point. I was thinking of creating a class inheriting from SslHandler, overriding its handleDownstream function to call context.sendDownstream(evt) after some point in the communication.
Question 1: Is this a bad idea, that is, disabling SSL at some point ?
To allow a block in the pipeline (say a Decoder) telling another block (say SslHandler) that it should change its behaviour from now on, I thought I could create, say, an AtomicBoolean in my ChannelPipelineFactory's getPipeline() and pass it to the constructor of both the Decoder and the SslHandler.
Question 2: Is this a bad idea, that is, sharing state between pipeline blocks ? I'm worried I might screw up the multithreading of Netty here: are the blocks of a pipeline working on a single message, one at a time ? i.e.: does the first block wait for the completion of the last block before pulling the next message ?
EDIT:
Oh my bad, this is from the ChannelPipeline page I had been visiting many times and quoting in this very question:
"A ChannelHandler can be added or removed at any time because a ChannelPipeline is thread safe. For example, you can insert a SslHandler when sensitive information is about to be exchanged, and remove it after the exchange."
So this answers question 2 about modifying the pipeline's content on-the-fly, and not the pipeline reference itself.
I'm not sure about the efficacy of turning off SSL once established, but I think you have misinterpreted the mutability of the pipeline. Once a given channel is associated with a pipeline, that association is immutable. However, the handlers in the pipeline can be safely modified. That is to say, you can add and remove handlers as your protocol requires. Accordingly,you should be able to remove the SSL handler once it has served its purpose.
You can remove SslHandler from the pipeline with ChannelPipeline.remove(..) then it should turn your connection to plaintext. Please file a bug if it does not work - we actually have not tried that scenario in production :-)
I'm not sure about Netty, but in principle, you could indeed carry on with plain traffic on the same TCP connection. There are a few downsides:
Only the authentication would be secured. A MITM could perform actions other than those intended by the user. (This is similar to using HTTP Digest to some extent: the credentials are protected, but the request/response entities aren't.)
From an implementation point of view, this is tricky to get right. The TLS specification says:
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding
close_notify alert before indicating to the application layer that
the TLS connection has ended.
This implies that you're going to synchronise your stream somehow to wait for the close_notify response, before carrying on with your plain traffic.
The SSLEngine programming model is rather complex, and you may find that the Netty API isn't necessary handling this situation.
While it may make sense to want to save a few CPU cycles, most of the SSL/TLS overhead is in the handshake, which you'll be doing anyway. The symmetric cryptographic operations used for the actual encryption of the data are much less expensive. (You should try to measure this overhead to see if it really is a problem.)