Automate replication of row-level security from AWS Lake Formation to Amazon QuickSight

Post Syndicated from Vetri Natarajan original https://aws.amazon.com/blogs/big-data/automate-replication-of-row-level-security-from-aws-lake-formation-to-amazon-quicksight/

Amazon QuickSight is cloud-powered, serverless, and embeddable business intelligence (BI) service that makes it straightforward to deliver insights to your organization. As a fully managed service, Amazon QuickSight lets you create and publish interactive dashboards that can then be accessed from different devices and embedded into your applications, portals, and websites.

When authors create datasets, build dashboards, and share with end-users, the users will see the same data as the author, unless row-level security (RLS) is enabled in the Amazon QuickSight dataset. Amazon QuickSight also provides options to pass a reader’s identity to a data source using trusted identity propagation and apply RLS at the source. To learn more, see Centrally manage permissions for tables and views accessed from Amazon QuickSight with trusted identity propagation and Simplify access management with Amazon Redshift and AWS Lake Formation for users in an External Identity Provider.

However, there are a few requirements when using trusted identity propagation with Amazon QuickSight:

  • The authentication method for Amazon QuickSight must be using AWS IAM Identity Center.
  • The dataset created using trusted identity propagation will be a direct query dataset in Amazon QuickSight. QuickSight SPICE can’t be used with trusted identity propagation. This is because when using SPICE, data is imported (replicated) and therefore the entitlements at the source can’t be used when readers access the dashboard.

This post outlines a solution to automatically replicate the entitlements for readers from the source (AWS Lake Formation) to Amazon QuickSight. This solution can be used even when the authentication method in Amazon QuickSight is not using IAM Identity Center and can work with both direct query and SPICE datasets in Amazon QuickSight. This lets you take advantage of auto scaling that comes with SPICE. Although we focus on using a Lake Formation table that exists in the same account, you can extend the solution for cross-account tables as well. When extracting data filter rules for the table in another account, the execution role must have necessary access to the tables in the other account.

Use case overview

For this post, let’s consider a large financial institution that has implemented Lake Formation as its central data lake and entitlement management system. The institution aims to streamline access control and maintain a single source of truth for data permissions across its entire data ecosystem. By using Lake Formation for entitlement management, the financial institution can maintain a robust, scalable, and compliant data access control system that serves as the foundation for its data-driven operations and analytics initiatives. This approach is particularly crucial for maintaining compliance with financial regulations and maintaining data security. The analytics team wants to build an Amazon QuickSight dashboard for data and business teams.

Solution overview

This solution uses APIs of AWS Lake Formation and Amazon QuickSight to extract, transform, and store AWS Lake Formation data filters in a format that can be used in QuickSight.

The solution has four key steps:

  1. Extract and transform the row-level security (data filters) and permissions to data filters for tables of interest from AWS Lake Formation.
  2. Create a rules dataset in Amazon QuickSight.

We use the following key services:

The following diagram illustrates the solution architecture.

Prerequisites

To implement this solution, you should have following services enabled in the same account

  1. AWS Lake Formation and
  2. Amazon QuickSight
  3. AWS Identity and Access Management (IAM) permissions: Make sure you have necessary IAM permissions to perform operation across all the services mentioned in the solution overview above
  4. AWS Lake Formation table with data filters with right permissions
  5. Amazon QuickSight principals (Users or Groups)

The below section shows how you can create Amazon QuickSight groups and AWS Lake formation tables and data filters

Create groups in QuickSight

Create two groups in Amazon QuickSight: QuickSight_Readers and QuickSight_Authors. For instructions, see Create a group with the QuickSight console.

You can then form the Amazon Resource Names (ARNs) of the groups as follows. These will be used when granting permission in AWS Lake Formation for data filters.

  • arn:aws:quicksight:<<identity-region>>:<<AWSAcocuntId>>:group/<<namespace>>/QuickSight_Readers
  • arn:aws:quicksight:<<identity-region>>:<<AWSAcocuntId>>:group/<<namespace>>/QuickSight_Authors

You can also get the ARN of the groups by executing the Amazon QuickSight CLI command list-groups. The following screenshot shows the output.

Create a table in AWS Lake Formation

The following section is for example purposes and not necessary for production use of this solution. Complete the following steps to create a table in AWS Lake Formation using sample data. In this post, the table is called saas_sales.

  1. Download the file Saas Sales.csv.
  2. Upload the file to an Amazon S3 location.
  3. Create a table in AWS Lake Formation.

Create row-level security (data filter) in AWS Lake Formation

In AWS Lake Formation, data filters are used to filter the data in a table for an individual or group. Complete the following steps to create a data filter:

  1. Create a data filter called QuickSightReaderFilter in the table saas_sales. For Row-level access, enter the expression segment = 'Enterprise'.
  2. Grant the Amazon QuickSight group access to this data filter. Use the reader group ARN from the first step for SAML Users and groups.
  3. Grant the QuickSight_Authors group full access to the table. Use the reader group ARN from the first step for SAML Users and groups.
  4. (Optional) You can create another table called second_table and create another data filter called SecondFilter and grant permission to the QuickSight_Readers group.

Now that you have set up the table, permissions, and data filters, you can extract the row-level access details for the QuickSight_Readers and QuickSight_Authors groups and the saas_sales table in AWS Lake Formation, and create the rules dataset in Amazon QuickSight for the saas_sales table.

Extract and transform data filters and permissions from AWS Lake Formation using a Lambda function

In AWS Lake Formation, data filters are created for each table. There can be many tables in AWS Lake Formation. However, for a team or a project, there are only a specific set of tables that the BI developer is interested in. Therefore, choose a list of tables to track and update the data filters for. In a batch process, for each table in AWS Lake Formation, extract the data filter definitions and write them into Amazon S3 using AWS Lake Formation and Amazon S3 APIs.

We use the following AWS Lake Formation APIs to extract the data filter details and permissions:

  • ListDataCellFilters – This API is used to list all the data filters in each table that is required for the project
  • ListPermissions – This API is used to retrieve the permissions for each of the data filters extracted using the ListDataCellFilters API

The Lambda function covers three parts of the solution:

  • Extract the data filters and permissions to data filters for tables of interest from AWS Lake Formation
  • Transform the data filters and permission into a format usable in Amazon QuickSight
  • Persist the transformed data

Complete the following steps to create an AWS Lambda function:

  1. On the Lambda console, create a function called Lake_Formation_QuickSight_RLS. Use Python 3.12 as the runtime and create a new role for execution.
  2. Configure Lambda function timeout to 2 minutes. This can vary depending on the number of tables to be parsed and the number of data filters to be transformed.
  3. Attach the following permissions to the Lambda execution role:
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Sid": "VisualEditor0",
    "Effect": "Allow",
    "Action": [
    "lakeformation:ListDataCellsFilter",
    "lakeformation:ListPermissions"
    ],
    "Resource": "*"
    },
    {
    "Sid": "VisualEditor1",
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::<bucket_used_for_storage>/*"
    }
    ]
    }

  4. Set the following environment variables for the Lambda function:

    Name Value
    S3Bucket Value of the S3 bucket where the output files will be stored
    tablesToTrack List of tables to track as JSON converted to string
    Tmp /tmp

The Lambda function gets the list of tables and S3 bucket details from the environment variables. The list of tables is given as a JSON array converted to string. The JSON format is shown in the following code. The values for catalogId, DatabaseName, and Name can be fetched from the AWS Lake Formation console.

[
{
"CatalogId": "String",
"DatabaseName": "String",
"Name": "String"
}
]
  1. Add a folder named tmp.
  2. Download the zip file Lake_Formation_QuickSight_RLS.zip.
    Note: This is sample code for non-production usage. You should work with your security and legal teams to meet your organizational security, regulatory, and compliance requirements before deployment.
  3. For the Lambda function code, upload the downloaded .zip file to the Lambda function, on the Code tab.
  4. Provide necessary access to the execution role in AWS Lake Formation. Although the AWS Identity and Access Management (IAM) permissions are given to the Lambda execution role, explicit permission has to be given to the role in AWS Lake Formation for the Lambda function to get the details about the data filters. Therefore, you have to explicitly grant access to the execution role to limit the Lambda role to read-only admin. For more details, see Viewing data filters.

In the following sections, we explain what the Lambda function code does in more detail.

Extract data filters and permissions for data filters and tables in AWS Lake Formation

The main flow of the code takes the list of tables as input and extracts table and data filter permissions and data filter rules. The approach here is to get the permissions for the entire table and also for the data filters applied to the table. This way, both full access (table level) and partial access (data filter) can be extracted.

...
....
tablesToTrack= json.loads(os.environ["tablesToTrack"])
lf_client = boto3.client('lakeformation')
# For each table in the list get the data filter rules attached to the table.
for table in tablesToTrack:
df_response= lf_client.list_data_cells_filter(
Table= table
)
d_filters += df_response["DataCellsFilters"]

# Also, for each table in the list get the list of permissions at table level.
# This determines who has access to all rows in the table.
tresponse=lf_client.list_permissions(
Resource= {
"Table": table
}
)

d_permissions += tresponse["PrincipalResourcePermissions"]
transformDataFilterRules(d_filters)
# For each data filters fetched above, get the permissions.
# This determines the row level security for the tables.
for filter in d_filters:
p_response=lf_client.list_permissions(
Resource= {

"DataCellsFilter": {
"DatabaseName": filter ["DatabaseName"],
"Name": filter["Name"],
"TableCatalogId": filter["TableCatalogId"],
"TableName": filter["TableName"]
}

}
)
d_permissions += p_response["PrincipalResourcePermissions"]

transformFilterandTablePermissions(d_permissions)

Transform data filter definitions in to a format usable in Amazon QuickSight

The extracted permissions and filters are transformed to create a rules dataset in Amazon QuickSight. There are different ways to define data filters. The following figure illustrates some of the example transformations.

The function transformDataFilterRules in the following code can transform some of the OR and AND conditions into Amazon QuickSight acceptable format. The following are the details available in the transformed format:

  • Lake Formation catalog ID
  • Lake Formation database name
  • Lake Formation table name
  • Lake Formation data filter name
  • List of columns from all the tables provided in the input for which the data filter rules are defined

See the following code:

def transformDataFilterRules(rules):
global complete_transformed_filter_rules
transformed_filter_rules = []
filter_to_extract=[]
complete_transformed_filter_rules = []
col_headers=[]
col_headers.append("catalog")
col_headers.append("database")
col_headers.append("table")
col_headers.append("filter")

for rule in rules:
print(rule)
catalog=rule["TableCatalogId"]
database = rule["DatabaseName"]
table = rule["TableName"]
filter = rule["Name"]
row=[]
row.append(catalog)
row.append(database)
row.append(table)
row.append(filter)
logger.info(f"row==={row}")

f_conditions = re.split(' OR | or | and | AND ' , rule["RowFilter"]["FilterExpression"])

for f_condition in f_conditions:
logger.info(f"f_condition={f_condition}")
f_condition = f_condition.replace("(","")
f_condition = f_condition.replace(")","")
filter_rule_column= f_condition.split("=")
if len(filter_rule_column)>1:
filter_rule_column[0] = filter_rule_column[0].strip()
if not filter_rule_column[0].strip() in col_headers:
col_headers.append(filter_rule_column[0].strip())
i= col_headers.index(filter_rule_column[0].strip())
j= i- (len(row)-1)
if j>0:
for x in range(1, j):
row.append("")
logger.info(f"i={i} j={j} {filter_rule_column[1]}")
row.insert(i, filter_rule_column[1].replace("'",""))
print(row)
transformed_filter_rules.append(','.join(row))

row=[]
row.append(catalog)
row.append(database)
row.append(table)
row.append(filter)
max_columns = len(col_headers)
complete_transformed_filter_rules=[]
for rule in transformed_filter_rules:
r = rule.split(",")
to_fill = max_columns - len(r)
if to_fill>0:
for x in range(1, to_fill+1):
r.append("")
complete_transformed_filter_rules.append(','.join(r))

complete_transformed_filter_rules.insert(0,','.join(col_headers))

The following figure is an example of the transformed file. The file contains the columns for both tables. When creating a rules dataset for a specific table, the records are filtered for that table pulled into Amazon QuickSight.

The function transformFilterandTablePermissions in the following code snippet combines and transforms the table and data filter permissions into a flat structure that contains the following columns:

  • Amazon QuickSight group ARN
  • Lake Formation catalog ID
  • Lake Formation database name
  • Lake Formation table name
  • Lake Formation data filter name

See the following code:

def transformFilterandTablePermissions(permissions):
    global transformed_table_permissions,transformed_filter_permissions
    # Read and set table level access
    transformed_table_permissions = []
    transformed_filter_permissions = []
    transformed_filter_permissions.insert(0,"group,catalog,database,table,filter")
    transformed_table_permissions.insert(0,"group,catalog,database,table")
    
    for permission in permissions:
    group=""
    database=""
    table =""
    catalog=""
    
    p= permission["Permissions"]
    
    if "DESCRIBE" in p or "SELECT" in p:
    
    group = permission["Principal"]["DataLakePrincipalIdentifier"]
    if "Database" in permission["Resource"]:
    catalog=permission["Resource"]["Database"]["CatalogId"]
    database=permission["Resource"]["Database"]["Name"]
    table = "*"
    transformed_table_permissions.append(group + "," + catalog+ "," + database + "," + table)
    transformed_filter_permissions.append(group+"," +catalog + ","+ database + ","+ table)
    elif "TableWithColumns" in  permission["Resource"]  or "Table" in permission["Resource"]:
    if "TableWithColumns" in  permission["Resource"]:
    catalog=permission["Resource"]["TableWithColumns"]["CatalogId"]
    database = permission["Resource"]["TableWithColumns"]["DatabaseName"]
    table = permission["Resource"]["TableWithColumns"]["Name"]
    elif "Table" in  permission["Resource"]:
    catalog=permission["Resource"]["Table"]["CatalogId"]
    database = permission["Resource"]["Table"]["DatabaseName"]
    table = permission["Resource"]["Table"]["Name"]
    transformed_table_permissions.append( group + "," + catalog + "," + database + "," + table)
    transformed_filter_permissions.append(group+"," +catalog + ","+ database + ","+ table)
    elif "DataCellsFilter" in permission["Resource"]:
    catalog=permission["Resource"]["DataCellsFilter"]["TableCatalogId"]
    database = permission["Resource"]["DataCellsFilter"]["DatabaseName"]
    table = permission["Resource"]["DataCellsFilter"]["TableName"]
    filter = permission["Resource"]["DataCellsFilter"]["Name"]
    transformed_filter_permissions.append(group+"," +catalog + ","+ database + ","+ table+ ","+ filter)

The following figure is an example of the extracted data filter and table permissions. AWS Lake Formation can have data filters applied to any principal. However, we focus on the Amazon QuickSight principals:

  • The QuickSight_Authors ARN has full access to two tables. This is determined by transforming the table-level permissions in addition to the data filter permissions.
  • The QuickSight_Readers ARN has limited access based on filter conditions.

Store the transformed rules and permissions in two separate files in Amazon S3

The transformed rules and permissions are then persisted in a data store. In this solution, the transformed rules are written to an Amazon S3 location in CSV format. The name of the files created by the Lambda function are:

  • transformed_filter_permissions.csv
  • transformed_filter_rules.csv

See the following code:

with open("/tmp/transformed_table_permissions.csv", "w") as txt_file:
for line in transformed_table_permissions:
txt_file.write(line + "\n") # works with any number of elements in a line
txt_file.close()
s3 = boto3.resource('s3')
s3.meta.client.upload_file(Filename = "/tmp/transformed_table_permissions.csv", Bucket= os.environ['S3Bucket'], Key = "table-permissions/transformed_table_permissions.csv")

with open("/tmp/transformed_filter_permissions.csv", "w") as txt_file:
for line in transformed_filter_permissions:
txt_file.write(line + "\n") # works with any number of elements in a line
txt_file.close()

s3.meta.client.upload_file(Filename = "/tmp/transformed_filter_permissions.csv", Bucket= os.environ['S3Bucket'], Key = "filter-permissions/transformed_filter_permissions.csv")

with open("/tmp/transformed_filter_rules.csv", "w") as txt_file:
for line in complete_transformed_filter_rules:
txt_file.write(line + "\n") # works with any number of elements in a line
txt_file.close()

s3.meta.client.upload_file(Filename = "/tmp/transformed_filter_rules.csv", Bucket= os.environ['S3Bucket'], Key = "filter-rules/transformed_filter_rules.csv")

Create a rules dataset in Amazon QuickSight

In this section, we walk through the steps to create a rules dataset in Amazon QuickSight.

Create a table in Lake formation for the files

The first step is to create a table in AWS Lake Formation for the two files, transformed_filter_permissions.csv and transformed_filter_rules.csv.

Although you can directly use an Amazon S3 connector in Amazon QuickSight, creating a table and making the rules dataset using an Athena connector gives flexibility in writing custom SQL and using direct query. For the steps to bring an Amazon S3 location into AWS Lake Formation, see Creating tables.

For this post, the tables for the files are created in a separate database called quicksight_lf_transformation.

Grant permission for the tables to the QuickSight_Authors group

Grant permission in AWS Lake Formation for the two tables to the QuickSight_Authors group. This is essential for Amazon QuickSight authors to create a rules dataset in Amazon QuickSight. The following screenshot shows the permission details.

Create a rules dataset in Amazon QuickSight

Amazon QuickSight supports both user-level and group-level RLS. In this post, we use groups to enable RLS. To create the rules dataset, you first join the filter permissions table with the filter rules table on the columns catalog, database, table, and filter. Then you can filter the permissions to include the Amazon QuickSight principals, and include only the columns required for the dataset. The objective in this solution is to build a rules dataset for the saas_sales table.

Complete the following steps:

  1. On the Amazon QuickSight console, create a new Athena dataset.
  2. Specify the following:
    1. For Catalog, choose AWSDataCatalog.
    2. For Database, choose quicksight_lf_transformation.
    3. For Table, choose filter_permissions.
  3. Choose Edit/Preview data.
  4. Choose Add data.
  5. Choose Add source.
  6. Select Athena.
  7. Specify the following:
    1. For Catalog, choose AWSDataCatalog.
    2. For Database, choose quicksight_lf_transformation.
    3. For Table, choose filter_rules.

  8. Join the permissions table with the data filter rules table on the catalog, database, table and filter columns.
  9. Rename the column group as GroupArn. This needs to be done before filter is applied.
  10. Filter the data where column table equals saas_sales.
  11. Filter the data where column group is also filtered for values starting with arn:aws:quicksight (Amazon QuickSight principals).
  12. Exclude fields that are not part of the saas_sales table.
  13. Change Query mode to SPICE.
  14. Publish the dataset.

If your organization has a mapping of other principals to a Amazon QuickSight group or user, you can apply that mapping before joining the tables.

You can also write the following custom SQL to achieve the same result:

SELECT a."group" as GroupArn, segment FROM "QuickSight_lf_transformation"."filter_permissions" as a
left join
"QuickSight_lf_transformation"."filter_rules" as b
on
a.catalog = b.catalog and
a.database = b.database and
a."table" = b."table" and
a.filter = b.filter
where a."table" = 'saas_sales'
and a."group" like 'arn:aws:quicksight%'

  1. Name the dataset LakeFormationRLSDataSet and publish the dataset.

Test the row-level security

Now you’re ready to test the row-level security by publishing a dashboard as a user in the QuickSight_Authors group and then viewing the dashboard as a user in the QuickSight_Readers group.

Publish a dashboard as a QuickSight_Authors group user

As an author who belongs to the QuickSight_Authors group, the user will be able to see the saas_sales table in the Athena connector and all the data in the table. As shown in this section, all three segments are visible for the author when creating an analysis and viewing the published dashboard.

  1. Create a dataset by pulling data from the saas_sales table using the Athena connector.
  2. Attach LakeFormationRLSDataSet as the RLS dataset for the saas_sales dataset. For instructions, see Using row-level security with user-based rules to restrict access to a dataset.
  3. Create an analysis using the saas_sales dataset as an author who belongs to the QuickSight_Authors group.
  4. Publish the dashboard.
  5. Share the dashboard with the group QuickSight_Readers.

View the dashboard as a QuickSight_Readers group user

Complete the following steps to view the dashboard as a QuickSight_Readers group user:

  1. Log into Amazon QuickSight as a reader who belongs to the QuickSight_Readers group.

The user will be able to see only the segment Enterprise.

  1. Now, change the RLS in AWS Lake Formation, and set the segment to be SMB for the QuickSightReaderFilter.
  2. Run the Lambda function to export and transform the new data filter rules.
  3. Refresh the SPICE dataset LakeFormationRLSDataSet in Amazon QuickSight.
  4. When the refresh is complete, refresh the dashboard in the reader login.

Now the reader user will see SMB data.

Cleanup

Amazon QuickSight resources

  1. Delete the Amazon QuickSight dashboard and analysis created
  2. Delete the datasets saas_sales and LakeFormationRulesDataSet
  3. Delete the Athena data source
  4. Delete the QuickSight groups using the DeleteGroup API

AWS Lake Formation resources

  1. Delete the database quicksight_lf transformation created in AWS Lake Formation
  2. Revoke permission given to the Lambda execution role
  3. Delete the saas_sales table and data filters created
  4. If you have used Glue crawler to create the tables in AWS Lake Formation, remove the Glue crawler as well

Compute resources

  1. Delete the AWS Lambda function created
  2. Delete the AWS Lambda execution role associated with the lambda

Storage resources

  1. Empty the content of the Amazon S3 bucket created for this solution
  2. Delete the Amazon S3 bucket

Conclusion

This post explained how to replicate row-level security in AWS Lake Formation automatically in Amazon QuickSight. This makes sure that the SPICE dataset in QuickSight can use row-level access defined in Lake Formation.

This solution can also be extended for other data sources. The logic to programmatically extract the entitlements from the source and transform them into Amazon QuickSight format will vary by source. After the extract and transform are in place, it can scale to multiple teams in the organization. Although this post laid out a basic approach, the automation has to be either scheduled to run periodically or triggered based on events like data filters change or grant or revoke of AWS Lake Formation permissions to make sure that the entitlements remain in sync between AWS Lake Formation and Amazon QuickSight.

Try out this solution for your own use case, and share your feedback in the comments.


About the Authors

Vetri Natarajan is a Specialist Solutions Architect for Amazon QuickSight. Vetri has 15 years of experience implementing enterprise business intelligence (BI) solutions and greenfield data products. Vetri specializes in integration of BI solutions with business applications and enable data-driven decisions.

Ismael Murillo is a Solutions Architect for Amazon QuickSight. Before joining AWS, Ismael worked in Amazon Logistics (AMZL) with delivery station management, delivery service providers, and our customer actively in the field. Ismael focused on last mile delivery and delivery success. He designed and implemented many innovative solutions to help reduce cost, influence delivery success. He is also a United States Army Veteran, where he served for eleven years.

[$] Debian’s AWKward essential set

Post Syndicated from jzb original https://lwn.net/Articles/1019898/

The Debian project has the concept of essential
packages
, which provide the bare minimum functionality considered
absolutely necessary (or “essential”) for a system to
function. Packages tagged as essential, and the packages that are
required by the set of essential packages, are always installed as
part of a Debian system. However, Debian’s packaging rules do not
require developers to explicitly declare dependencies on that set of
packages (the essential set) but they can simply rely on the fact that those
will always be present. That means that changing the essential set, as
the project may wish to do occasionally, is more complicated than it
should be. This came to light recently when a Debian developer asked
what might be required to remove mawk to slim down
the project’s container images.

Deepin Desktop removed from openSUSE

Post Syndicated from jzb original https://lwn.net/Articles/1020407/

The SUSE Security Team has announced the removal of the Deepin
Desktop from openSUSE due to violations of the project’s packaging
policy.

The discovery of the bypass of the security whitelistings via the
deepin-feature-enable package marks a turning point in our assessment
of Deepin. We don’t believe that the openSUSE Deepin packager acted
with bad intent when he implemented the “license agreement” dialog to
bypass our whitelisting restrictions. The dialog itself makes the
security concerns we have transparent, so this does not happen in a
sneaky way, at least not towards users. It was not discussed with us,
however, and it violates openSUSE packaging policies. Beyond the
security aspect, this also affects general packaging quality
assurance: the D-Bus configuration files and Polkit policies installed
by the deepin-feature-enable package are unknown to the package
manager and won’t be cleaned up upon package removal, for
example. Such bypasses are not deemed acceptable by us.

The combination of these factors led us to the decision to remove
the Deepin desktop completely from openSUSE Tumbleweed and from the
future Leap 16.0 release. In openSUSE Leap 15.6 we will remove the
offending deepin-feature-enable package only. It is a difficult
decision given that the Deepin desktop has a considerable number of
users. We firmly believe the Deepin packaging and security assessment
in openSUSE needs a reboot, however, ideally involving new people that
can help get the Deepin packages into shape, establish a relationship
with Deepin upstream and keep an eye on bugfixes, thus avoiding
fruitless follow-up reviews that just waste our time. In such a new
setup we would be willing to have a look at all the sensitive Deepin
components again one by one.

The announcement goes into detail about the bypass of
openSUSE packaging policy and the history of security reviews of
Deepin components. It also offers guidance on continuing
to use Deepin Desktop
on openSUSE.

In the works – AWS South America (Chile) Region

Post Syndicated from Elizabeth Fuentes original https://aws.amazon.com/blogs/aws/coming-soon-aws-south-america-chile-region/

Today, Amazon Web Services (AWS) announced plans to launch a new AWS Region in Chile by the end of 2026. The AWS South America (Chile) Region will consist of three Availability Zones at launch, bringing AWS infrastructure and services closer to customers in Chile. This new Region joins the AWS South America (São Paulo) and AWS Mexico (Central) Regions as our third AWS Region in Latin America. Each Availability Zone is separated by a meaningful distance to support applications that need low latency while significantly reducing the risk of a single event impacting availability.

Skyline of Santiago de Chile with modern office buildings in the financial district in Las Condes

The new AWS Region will bring advanced cloud technologies, including artificial intelligence (AI) and machine learning (ML), closer to customers in Latin America. Through high-bandwidth, low-latency network connections over dedicated, fully redundant fiber, the Region will support applications requiring synchronous replication while giving you the flexibility to run workloads and store data locally to meet data residency requirements.

AWS in Chile
In 2017, AWS established an office in Santiago de Chile to support local customers and partners. Today, there are business development teams, solutions architects, partner managers, professional services consultants, support staff, and personnel in various other roles working in the Santiago office.

As part of our ongoing commitment to Chile, AWS has invested in several infrastructure offerings throughout the country. In 2019, AWS launched an Amazon CloudFront edge location in Chile. This provides a highly secure and programmable content delivery network that accelerates the delivery of data, videos, applications, and APIs to users worldwide with low latency and high transfer speeds.

AWS strengthened its presence in 2021 with two significant additions. First, an AWS Ground Station antenna location in Punta Arenas, offering a fully managed service for satellite communications, data processing, and global satellite operations scaling. Second, AWS Outposts in Chile, bringing fully managed AWS infrastructure and services to virtually any on-premises or edge location for a consistent hybrid experience.

In 2023, AWS further enhanced its infrastructure with two key developments, an AWS Direct Connect location in Chile that lets you create private connectivity between AWS and your data center, office, or colocation environment, and AWS Local Zones in Santiago, placing compute, storage, database, and other select services closer to large population centers and IT hubs. The AWS Local Zone in Santiago helps customers deliver applications requiring single-digit millisecond latency to end users.

The upcoming AWS South America (Chile) Region represents our continued commitment to fueling innovation in Chile. Beyond building infrastructure, AWS plays a crucial role in developing Chile’s digital workforce through comprehensive cloud education initiatives. Through AWS Academy, AWS Educate, and AWS Skill Builder, AWS provides essential cloud computing skills to diverse groups—from students and developers to business professionals and emerging IT leaders. Since 2017, AWS has trained more than two million people across Latin America on cloud skills, including more than 100,000 in Chile.

AWS customers in Chile
AWS customers in Chile have been increasingly moving their applications to AWS and running their technology infrastructure in AWS Regions around the world. With the addition of this new AWS Region, customers will be able to provide even lower latency to end users and use advanced technologies such as generative AI, Internet of Things (IoT), mobile services, banking industry, and more, to drive innovation. This Region will give AWS customers the ability to run their workloads and store their content in Chile.

Here are some examples of customers in Chile using AWS to drive innovation:

The Digital Government Secretariat (SGD) is the Chilean government institution responsible for proposing and coordinating the implementation of the Digital Government Strategy, providing an integrated government approach. SGD coordinates, advises, and provides cross-sector support in the strategic use of digital technologies, data, and public information to improve state administration and service delivery. To fulfill this mission, SGD relies on AWS to operate critical digital platforms including Clave Única (single sign-on), FirmaGob (digital signature), the State Electronic Services Integration Platform (PISEE), DocDigital, SIMPLE, and the Administrative Procedures and Services Catalog (CPAT), among others.

Transbank, Chile’s largest payment solutions ecosystem managing the largest percentage of national transactions, used AWS to significantly reduce time-to-market for new products. Moreover, Transbank implemented multiple AWS-powered solutions, enhancing team productivity and accelerating innovation. These initiatives showcase how financial technology companies can use AWS to drive innovation and operational efficiency. “The new AWS Region in Chile will be very important for us,” said Jorge Rodríguez M., Chief Architecture and Technology Officer (CA&TO) of Transbank. “It will further reduce latency, improve security and expand the possibilities for innovation, allowing us to serve our customers with new and better services and products.”

To learn more about AWS customers in Chile, visit AWS Customer Success Stories.

AWS sustainability efforts in Chile
AWS is committed to water stewardship in Chile through innovative conservation projects. In the Maipo Basin, which provides essential water for the Metropolitan Santiago and Valparaiso regions, AWS has partnered with local farmers and climate-tech company Kilimo to implement water-saving initiatives. The project involves converting 67 hectares of agricultural land from flood to drip irrigation, which will save approximately 200 million liters of water annually.

This water conservation effort supports AWS commitment to be water positive by 2030 and demonstrates our dedication to environmental sustainability in the communities where AWS operate. The project uses efficient drip irrigation systems that deliver water directly to plant root systems through a specialized pipe network, maximizing water efficiency for agricultural use. To learn more about this initiative, read our blog post AWS expands its water replenishment program to China and Chile—and adds projects in the US and Brazil.

AWS community in Chile
The AWS community in Chile is one of the most active in the region, comprising of AWS Community Builders, two AWS User Groups (AWS User Group Chile and AWS Girls Chile), and an AWS Cloud Club. These groups hold monthly events and have organized two AWS Community Days. At the first Community Day, held in 2023, we had the honor of having Jeff Barr as the keynote speaker.

Chile AWS Community Day 2023

Stay tuned
We’ll announce the opening of this and the other Regions in future blog posts, so be sure to stay tuned! To learn more, visit the AWS Region in Chile page.

— Eli

Thanks to Leonardo Vilacha for the Chile AWS Community Day 2023 photo.


How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

Security updates for Wednesday

Post Syndicated from jzb original https://lwn.net/Articles/1020404/

Security updates have been issued by Fedora (incus and nodejs20), Red Hat (freetype, kernel, kernel-rt, libsoup, libtiff, redis, redis:6, and thunderbird), SUSE (apparmor, chromium, grafana, ImageMagick, java-11-openjdk, java-17-openjdk, libsoup, libsoup2, libxslt, opensaml, rabbitmq-server, rubygem-rack-1_6, sqlite3, and thunderbird), and Ubuntu (kernel, libfcgi, libraw, libsoup2.4, linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-igx, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure-5.4, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-kvm, linux-oracle, linux-oracle-5.4, linux, linux-aws, linux-aws-6.8, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-hwe-6.8, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oem-6.8, linux-oracle, linux-oracle-6.8, linux, linux-aws, linux-aws-hwe, linux-gcp, linux-gcp-4.15, linux-hwe, linux-kvm, linux-oracle, linux, linux-aws, linux-gcp, linux-gcp-6.11, linux-hwe-6.11, linux-lowlatency, linux-lowlatency-hwe-6.11, linux-oracle, linux-raspi, linux-aws-fips, linux-fips, linux-gcp-fips, linux-azure, linux-azure, linux-azure-4.15, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-azure, linux-azure-6.11, linux-azure-6.8, linux-azure-fips, linux-intel-iot-realtime, linux-realtime, linux-oem-6.11, linux-raspi, linux-realtime, python, python-scrapy, and ruby-carrierwave).

QUIC restarts, slow problems: udpgrm to the rescue

Post Syndicated from Marek Majkowski original https://blog.cloudflare.com/quic-restarts-slow-problems-udpgrm-to-the-rescue/

At Cloudflare, we do everything we can to avoid interruption to our services. We frequently deploy new versions of the code that delivers the services, so we need to be able to restart the server processes to upgrade them without missing a beat. In particular, performing graceful restarts (also known as “zero downtime”) for UDP servers has proven to be surprisingly difficult.

We’ve previously written about graceful restarts in the context of TCP, which is much easier to handle. We didn’t have a strong reason to deal with UDP until recently — when protocols like HTTP3/QUIC became critical. This blog post introduces udpgrm, a lightweight daemon that helps us to upgrade UDP servers without dropping a single packet.

Here’s the udpgrm GitHub repo.

Historical context

In the early days of the Internet, UDP was used for stateless request/response communication with protocols like DNS or NTP. Restarts of a server process are not a problem in that context, because it does not have to retain state across multiple requests. However, modern protocols like QUIC, WireGuard, and SIP, as well as online games, use stateful flows. So what happens to the state associated with a flow when a server process is restarted? Typically, old connections are just dropped during a server restart. Migrating the flow state from the old instance to the new instance is possible, but it is complicated and notoriously hard to get right.

The same problem occurs for TCP connections, but there a common approach is to keep the old instance of the server process running alongside the new instance for a while, routing new connections to the new instance while letting existing ones drain on the old. Once all connections finish or a timeout is reached, the old instance can be safely shut down. The same approach works for UDP, but it requires more involvement from the server process than for TCP.

In the past, we described the established-over-unconnected method. It offers one way to implement flow handoff, but it comes with significant drawbacks: it’s prone to race conditions in protocols with multi-packet handshakes, and it suffers from a scalability issue. Specifically, the kernel hash table used for dispatching packets is keyed only by the local IP:port tuple, which can lead to bucket overfill when dealing with many inbound UDP sockets.

Now we have found a better method, leveraging Linux’s SO_REUSEPORT API. By placing both old and new sockets into the same REUSEPORT group and using an eBPF program for flow tracking, we can route packets to the correct instance and preserve flow stickiness. This is how udpgrm works.

REUSEPORT group

Before diving deeper, let’s quickly review the basics. Linux provides the SO_REUSEPORT socket option, typically set after socket() but before bind(). Please note that this has a separate purpose from the better known SO_REUSEADDR socket option.

SO_REUSEPORT allows multiple sockets to bind to the same IP:port tuple. This feature is primarily used for load balancing, letting servers spread traffic efficiently across multiple CPU cores. You can think of it as a way for an IP:port to be associated with multiple packet queues. In the kernel, sockets sharing an IP:port this way are organized into a reuseport group — a term we’ll refer to frequently throughout this post.

┌───────────────────────────────────────────┐
│ reuseport group 192.0.2.0:443             │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ socket #1 │ │ socket #2 │ │ socket #3 │ │
│ └───────────┘ └───────────┘ └───────────┘ │
└───────────────────────────────────────────┘

Linux supports several methods for distributing inbound packets across a reuseport group. By default, the kernel uses a hash of the packet’s 4-tuple to select a target socket. Another method is SO_INCOMING_CPU, which, when enabled, tries to steer packets to sockets running on the same CPU that received the packet. This approach works but has limited flexibility.

To provide more control, Linux introduced the SO_ATTACH_REUSEPORT_CBPF option, allowing server processes to attach a classic BPF (cBPF) program to make socket selection decisions. This was later extended with SO_ATTACH_REUSEPORT_EBPF, enabling the use of modern eBPF programs. With eBPF, developers can implement arbitrary custom logic. A boilerplate program would look like this:

SEC("sk_reuseport")
int udpgrm_reuseport_prog(struct sk_reuseport_md *md)
{
    uint64_t socket_identifier = xxxx;
    bpf_sk_select_reuseport(md, &sockhash, &socket_identifier, 0);
    return SK_PASS;
}

To select a specific socket, the eBPF program calls bpf_sk_select_reuseport, using a reference to a map with sockets (SOCKHASH, SOCKMAP, or the older, mostly obsolete SOCKARRAY), along with a key or index. For example, a declaration of a SOCKHASH might look like this:

struct {
	__uint(type, BPF_MAP_TYPE_SOCKHASH);
	__uint(max_entries, MAX_SOCKETS);
	__uint(key_size, sizeof(uint64_t));
	__uint(value_size, sizeof(uint64_t));
} sockhash SEC(".maps");

This SOCKHASH is a hash map that holds references to sockets, even though the value size looks like a scalar 8-byte value. In our case it’s indexed by an uint64_t key. This is pretty neat, as it allows for a simple number-to-socket mapping!

However, there’s a catch: the SOCKHASH must be populated and maintained from user space (or a separate control plane), outside the eBPF program itself. Keeping this socket map accurate and in sync with the server process state is surprisingly difficult to get right — especially under dynamic conditions like restarts, crashes, or scaling events. The point of udpgrm is to take care of this stuff, so that server processes don’t have to.

Socket generation and working generation

Let’s look at how graceful restarts for UDP flows are achieved in udpgrm. To reason about this setup, we’ll need a bit of terminology: A socket generation is a set of sockets within a reuseport group that belong to the same logical application instance:

┌───────────────────────────────────────────────────┐
│ reuseport group 192.0.2.0:443                     │
│  ┌─────────────────────────────────────────────┐  │
│  │ socket generation 0                         │  │
│  │  ┌───────────┐ ┌───────────┐ ┌───────────┐  │  │
│  │  │ socket #1 │ │ socket #2 │ │ socket #3 │  │  │
│  │  └───────────┘ └───────────┘ └───────────┘  │  │
│  └─────────────────────────────────────────────┘  │
│  ┌─────────────────────────────────────────────┐  │
│  │ socket generation 1                         │  │
│  │  ┌───────────┐ ┌───────────┐ ┌───────────┐  │  │
│  │  │ socket #4 │ │ socket #5 │ │ socket #6 │  │  │
│  │  └───────────┘ └───────────┘ └───────────┘  │  │
│  └─────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────┘

When a server process needs to be restarted, the new version creates a new socket generation for its sockets. The old version keeps running alongside the new one, using sockets from the previous socket generation.

Reuseport eBPF routing boils down to two problems:

  • For new flows, we should choose a socket from the socket generation that belongs to the active server instance.

  • For already established flows, we should choose the appropriate socket — possibly from an older socket generation — to keep the flows sticky. The flows will eventually drain away, allowing the old server instance to shut down.

Easy, right?

Of course not! The devil is in the details. Let’s take it one step at a time.

Routing new flows is relatively easy. udpgrm simply maintains a reference to the socket generation that should handle new connections. We call this reference the working generation. Whenever a new flow arrives, the eBPF program consults the working generation pointer and selects a socket from that generation.

┌──────────────────────────────────────────────┐
│ reuseport group 192.0.2.0:443                │
│   ...                                        │
│   Working generation ────┐                   │
│                          V                   │
│           ┌───────────────────────────────┐  │
│           │ socket generation 1           │  │
│           │  ┌───────────┐ ┌──────────┐   │  │
│           │  │ socket #4 │ │ ...      │   │  │
│           │  └───────────┘ └──────────┘   │  │
│           └───────────────────────────────┘  │
│   ...                                        │
└──────────────────────────────────────────────┘

For this to work, we first need to be able to differentiate packets belonging to new connections from packets belonging to old connections. This is very tricky and highly dependent on the specific UDP protocol. For example, QUIC has an initial packet concept, similar to a TCP SYN, but other protocols might not.

There needs to be some flexibility in this and udpgrm makes this configurable. Each reuseport group sets a specific flow dissector.

Flow dissector has two tasks:

  • It distinguishes new packets from packets belonging to old, already established flows.

  • For recognized flows, it tells udpgrm which specific socket the flow belongs to.

These concepts are closely related and depend on the specific server. Different UDP protocols define flows differently. For example, a naive UDP server might use a typical 5-tuple to define flows, while QUIC uses a “connection ID” field in the QUIC packet header to survive NAT rebinding.

udpgrm supports three flow dissectors out of the box and is highly configurable to support any UDP protocol. More on this later.

Welcome udpgrm!

Now that we covered the theory, we’re ready for the business: please welcome udpgrm — UDP Graceful Restart Marshal! udpgrm is a stateful daemon that handles all the complexities of the graceful restart process for UDP. It installs the appropriate eBPF REUSEPORT program, maintains flow state, communicates with the server process during restarts, and reports useful metrics for easier debugging.

We can describe udpgrm from two perspectives: for administrators and for programmers.

udpgrm daemon for the system administrator

udpgrm is a stateful daemon, to run it:

$ sudo udpgrm --daemon
[ ] Loading BPF code
[ ] Pinning bpf programs to /sys/fs/bpf/udpgrm
[*] Tailing message ring buffer  map_id 936146

This sets up the basic functionality, prints rudimentary logs, and should be deployed as a dedicated systemd service — loaded after networking. However, this is not enough to fully use udpgrm. udpgrm needs to hook into getsockopt, setsockopt, bind, and sendmsg syscalls, which are scoped to a cgroup. To install the udpgrm hooks, you can install it like this:

$ sudo udpgrm --install=/sys/fs/cgroup/system.slice

But a more common pattern is to install it within the current cgroup:

$ sudo udpgrm --install --self

Better yet, use it as part of the systemd “service” config:

[Service]
...
ExecStartPre=/usr/local/bin/udpgrm --install --self

Once udpgrm is running, the administrator can use the CLI to list reuseport groups, sockets, and metrics, like this:

$ sudo udpgrm list
[ ] Retrievieng BPF progs from /sys/fs/bpf/udpgrm
192.0.2.0:4433
	netns 0x1  dissector bespoke  digest 0xdead
	socket generations:
		gen  3  0x17a0da  <=  app 0  gen 3
	metrics:
		rx_processed_total 13777528077
...

Now, with both the udpgrm daemon running, and cgroup hooks set up, we can focus on the server part.

udpgrm for the programmer

We expect the server to create the appropriate UDP sockets by itself. We depend on SO_REUSEPORT, so that each server instance can have a dedicated socket or a set of sockets:

sd = socket.socket(AF_INET, SOCK_DGRAM, 0)
sd.setsockopt(SOL_SOCKET, SO_REUSEPORT, 1)
sd.bind(("192.0.2.1", 5201))

With a socket descriptor handy, we can pursue the udpgrm magic dance. The server communicates with the udpgrm daemon using setsockopt calls. Behind the scenes, udpgrm provides eBPF setsockopt and getsockopt hooks and hijacks specific calls. It’s not easy to set up on the kernel side, but when it works, it’s truly awesome. A typical socket setup looks like this:

try:
    work_gen = sd.getsockopt(IPPROTO_UDP, UDP_GRM_WORKING_GEN)
except OSError:
    raise OSError('Is udpgrm daemon loaded? Try "udpgrm --self --install"')
    
sd.setsockopt(IPPROTO_UDP, UDP_GRM_SOCKET_GEN, work_gen + 1)
for i in range(10):
    v = sd.getsockopt(IPPROTO_UDP, UDP_GRM_SOCKET_GEN, 8);
    sk_gen, sk_idx = struct.unpack('II', v)
    if sk_idx != 0xffffffff:
        break
    time.sleep(0.01 * (2 ** i))
else:
    raise OSError("Communicating with udpgrm daemon failed.")

sd.setsockopt(IPPROTO_UDP, UDP_GRM_WORKING_GEN, work_gen + 1)

You can see three blocks here:

  • First, we retrieve the working generation number and, by doing so, check for udpgrm presence. Typically, udpgrm absence is fine for non-production workloads.

  • Then we register the socket to an arbitrary socket generation. We choose work_gen + 1 as the value and verify that the registration went through correctly.

  • Finally, we bump the working generation pointer.

That’s it! Hopefully, the API presented here is clear and reasonable. Under the hood, the udpgrm daemon installs the REUSEPORT eBPF program, sets up internal data structures, collects metrics, and manages the sockets in a SOCKHASH.

Advanced socket creation with udpgrm_activate.py

In practice, we often need sockets bound to low ports like :443, which requires elevated privileges like CAP_NET_BIND_SERVICE. It’s usually better to configure listening sockets outside the server itself. A typical pattern is to pass the listening sockets using socket activation.

Sadly, systemd cannot create a new set of UDP SO_REUSEPORT sockets for each server instance. To overcome this limitation, udpgrm provides a script called udpgrm_activate.py, which can be used like this:

[Service]
Type=notify                 # Enable access to fd store
NotifyAccess=all            # Allow access to fd store from ExecStartPre
FileDescriptorStoreMax=128  # Limit of stored sockets must be set

ExecStartPre=/usr/local/bin/udpgrm_activate.py test-port 0.0.0.0:5201

Here, udpgrm_activate.py binds to 0.0.0.0:5201 and stores the created socket in the systemd FD store under the name test-port. The server echoserver.py will inherit this socket and receive the appropriate FD_LISTEN environment variables, following the typical systemd socket activation pattern.

Systemd service lifetime

Systemd typically can’t handle more than one server instance running at the same time. It prefers to kill the old instance quickly. It supports the “at most one” server instance model, not the “at least one” model that we want. To work around this, udpgrm provides a decoy script that will exit when systemd asks it to, while the actual old instance of the server can stay active in the background.

[Service]
...
ExecStart=/usr/local/bin/mmdecoy examples/echoserver.py

Restart=always             # if pid dies, restart it.
KillMode=process           # Kill only decoy, keep children after stop.
KillSignal=SIGTERM         # Make signals explicit

At this point, we showed a full template for a udpgrm enabled server that contains all three elements: udpgrm --install --self for cgroup hooks, udpgrm_activate.py for socket creation, and mmdecoy for fooling systemd service lifetime checks.

[Service]
Type=notify                 # Enable access to fd store
NotifyAccess=all            # Allow access to fd store from ExecStartPre
FileDescriptorStoreMax=128  # Limit of stored sockets must be set

ExecStartPre=/usr/local/bin/udpgrm --install --self
ExecStartPre=/usr/local/bin/udpgrm_activate.py --no-register test-port 0.0.0.0:5201
ExecStart=/usr/local/bin/mmdecoy PWD/examples/echoserver.py

Restart=always             # if pid dies, restart it.
KillMode=process           # Kill only decoy, keep children after stop. 
KillSignal=SIGTERM         # Make signals explicit

Dissector modes

We’ve discussed the udpgrm daemon, the udpgrm setsockopt API, and systemd integration, but we haven’t yet covered the details of routing logic for old flows. To handle arbitrary protocols, udpgrm supports three dissector modes out of the box:

DISSECTOR_FLOW: udpgrm maintains a flow table indexed by a flow hash computed from a typical 4-tuple. It stores a target socket identifier for each flow. The flow table size is fixed, so there is a limit to the number of concurrent flows supported by this mode. To mark a flow as “assured,” udpgrm hooks into the sendmsg syscall and saves the flow in the table only when a message is sent.

DISSECTOR_CBPF: A cookie-based model where the target socket identifier — called a udpgrm cookie — is encoded in each incoming UDP packet. For example, in QUIC, this identifier can be stored as part of the connection ID. The dissection logic is expressed as cBPF code. This model does not require a flow table in udpgrm but is harder to integrate because it needs protocol and server support.

DISSECTOR_NOOP: A no-op mode with no state tracking at all. It is useful for traditional UDP services like DNS, where we want to avoid losing even a single packet during an upgrade.

Finally, udpgrm provides a template for a more advanced dissector called DISSECTOR_BESPOKE. Currently, it includes a QUIC dissector that can decode the QUIC TLS SNI and direct specific TLS hostnames to specific socket generations.

For more details, please consult the udpgrm README. In short: the FLOW dissector is the simplest one, useful for old protocols. CBPF dissector is good for experimentation when the protocol allows storing a custom connection id (cookie) — we used it to develop our own QUIC Connection ID schema (also named DCID) — but it’s slow, because it interprets cBPF inside eBPF (yes really!). NOOP is useful, but only for very specific niche servers. The real magic is in the BESPOKE type, where users can create arbitrary, fast, and powerful dissector logic.

Summary

The adoption of QUIC and other UDP-based protocols means that gracefully restarting UDP servers is becoming an increasingly important problem. To our knowledge, a reusable, configurable and easy to use solution didn’t exist yet. The udpgrm project brings together several novel ideas: a clean API using setsockopt(), careful socket-stealing logic hidden under the hood, powerful and expressive configurable dissectors, and well-thought-out integration with systemd.

While udpgrm is intended to be easy to use, it hides a lot of complexity and solves a genuinely hard problem. The core issue is that the Linux Sockets API has not kept up with the modern needs of UDP.

Ideally, most of this should really be a feature of systemd. That includes supporting the “at least one” server instance mode, UDP SO_REUSEPORT socket creation, installing a REUSEPORT_EBPF program, and managing the “working generation” pointer. We hope that udpgrm helps create the space and vocabulary for these long-term improvements.

Exploring an Untethered, Unified Approach to CTEM

Post Syndicated from Joel Alcon original https://blog.rapid7.com/2025/05/07/exploring-an-untethered-unified-approach-to-ctem/

Exploring an Untethered, Unified Approach to CTEM

We live in a world where traditional Vulnerability Management (VM) has become infosec’s version of ‘whack-a-mole’— an attempt to tackle risks that constantly shift, multiply, and morph. As organizations push workloads to the cloud, offer customers digital experiences, or as they build AI-enabled applications across  their business, the attack surface expands exponentially. For decades, security teams have relied on traditional network and endpoint-based scanners to discover and patch CVEs, but the reality is attackers don’t think in terms of “CVEs”—they think in attack paths.

The most successful hackers increase the blast radius and impact of their attacks by connecting key dots across your organization:

  • Weak access controls to high-privilege users.
  • Misconfigurations to mission-critical assets.
  • Known exploits to number of impacted systems.

To tame this complicated, quickly-evolving threat landscape, security teams are moving from ticking boxes for vulnerabilities patched, to understanding, contextualizing, and preempting real-world threats before they become breaches. The strategic shift has fueled the rise of Risk-Based Vulnerability Management (RBVM) and Continuous Threat Exposure Management (CTEM).

However, many organizations implement these approaches through an array of point security solutions – vulnerability scanners, endpoint detection software, penetration testing – and feed this data into one or more aggregation tools (usually SIEMs). This fragmented approach has inadvertently paved the way for tool sprawl, operational silos, and security blind spots. In this blog, I’ll explore why RBVM and CTEM have become essential security strategies, common mistakes that organizations make in implementation, and why these shortcomings have fueled the demand for unified exposure management.

RBVM helps teams prioritize remediation based on exploitability, criticality, and threat intelligence, rather than relying solely on CVE severity scores. RBVM solutions typically ingest data from vulnerability scanners, external threat feeds, endpoint detection systems, and other security tools. Security analysts then correlate key findings against SIEM tools to determine which vulnerabilities are actively being exploited in their environment.

The key benefit? This approach reduces alert noise because it filters out low-risk vulnerabilities, enabling security teams to focus remediation efforts on the most critical threats.

However, RBVM approaches come with significant drawbacks:

  • RBVM tools are not designed to perform scans or produce threat intel themselves.
  • Teams must integrate RBVM solutions into their existing security stack (SIEM, SOAR, EDR, cloud security tools) – a process that’s often complex, time-consuming, and costly.
  • Most critically, if there are assets that the RVBM services have no visibility into, they will not produce risk scores for them, creating an incomplete picture of your attack surface and inaccurate representation of true business threats.

The evolution to CTEM

To continuously assess and validate exposures across the entire attack surface, organizations are turning to CTEM as a proactive strategy for mitigating ongoing risk. With real-time, continuous visibility into the attack surface and attack paths, security teams can prioritize remediation efforts based on the risks that impact business-critical systems. Despite the benefits of this more advanced approach, implementing CTEM with fragmented security tools creates significant challenges:

Misleading view of the attack surface.

Your security stack may have top-tier vulnerability scanners, EDR solutions, and CSPM tools, but if these tools aren’t talking to each other, you end up with an incomplete view of the attack paths that hackers would take. Leading CTEM approaches are underpinned by platforms that go beyond CVEs by incorporating misconfigurations, cloud entitlements, shadow IT, lateral movement risks, and application security gaps to provide a comprehensive view of the attack surface.

Lacking business content and impact analysis for prioritization.

Security teams have to sort through alerts, false positives, and vulnerability scan results that often lack business context. Without a unified platform connecting vulnerability findings with risk scores and business impact, teams will struggle to accurately prioritize risk, leaving them spending valuable time remediating issues that do not actually impact business-critical systems. Organizations need to look across the entire attack surface, including internal and external-facing attack vectors, as well as telemetry signals like weak identity and access controls.

Silos hinder incident response.

Vulnerability dashboards and reports do not depict how an adversary would exploit a vulnerability. Organizations need an in-depth view of the attack path to understand, for example, how misconfigurations can result in disruptive domain compromise in the event of a breach. This insight helps security teams identify interconnected systems and organizational peers (e.g., application owners, cloud architects, developers, engineers, etc.) that they will need to coordinate with in case there is a breach.

The driving force for a unified exposure management platform

According to the 2023 Gartner® Technology Adoption Roadmap for Large Enterprises Survey, cybersecurity leaders indicated that on average their organizations had 43 tools in their cybersecurity product portfolios, and 5% of the leaders indicated their organizations had over 100 tools.” We believe that managing that many tools can be overwhelming, especially because security teams often operate their tools in silos. The ensuing sprawl creates blind spots that attackers can easily exploit. Instead of juggling multiple disconnected tools, forward-thinking organizations are embracing a unified approach to exposure management with comprehensive platforms that deliver:

  • Vulnerability management
  • CASM
  • EASM
  • Cloud security
  • Identity security
  • Threat intelligence

Because many high-profile breaches start with compromised credentials or excessive privileges, the ideal exposure management platform maps critical assets against users with weak authentication protocols.

Security teams can no longer rely on a scan-and-patch approach; they need to stay ahead of attackers by continuously identifying, validating, and mitigating risks across the entire attack surface. If your security tools aren’t fully integrated, attackers will exploit what’s left exposed. CISOs, security architects, and SOC leaders are tackling this challenge by moving beyond traditional VM and adopting a unified exposure management strategy with Rapid7’s Exposure Command Platform.

Connecting the dots with Exposure Command

Unlike traditional standalone VM, CASM, EASM, SIEM, or EDR tools that rely on proprietary agents, Exposure Command from Rapid7 brings it all together into one platform. With an inside-out and outside-in view of your risks, combined with trusted threat intelligence and a vendor agnostic approach to vulnerability aggregation, security teams gain a complete, end-to-end view of their attack surface.

Rapid7’s all-in-one Exposure Command platform goes even further by automatically mapping users, authentication protocols, and the criticality of the systems they can access. Armed with deep visibility into vulnerabilities and their impact to the business, organizations can leverage Rapid7’s Remediation Hub to address the risks that have the largest impact on their overall risk posture.

The paradigm has shifted – it’s no longer about chasing vulnerability patches, but about taking command and reducing risk across the business.

Ready to see the difference a unified approach can make? Check out the Rapid7 Exposure Command product trial to learn more about our platform and dive deeper into our unified, modern approach to managing risk and remediating security threats.

Gartner, Infrastructure Security Primer for 2025, John Watts, Franz Hinner, 29 January 2025 (For Gartner subscribers only)

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

Chinese AI Submersible

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2025/05/chinese-ai-submersible.html

A Chinese company has developed an AI-piloted submersible that can reach speeds “similar to a destroyer or a US Navy torpedo,” dive “up to 60 metres underwater,” and “remain static for more than a month, like the stealth capabilities of a nuclear submarine.” In case you’re worried about the military applications of this, you can relax because the company says that the submersible is “designated for civilian use” and can “launch research rockets.”

“Research rockets.” Sure.

Абдулсамед Вели: Промяната идва отвътре

Post Syndicated from Ина Иванова original https://www.toest.bg/abdulsamed-veli-promyanata-idva-otvutre/

Абдулсамед Вели: Промяната идва отвътре

Името му означава „слуга на Аллах“ и той се старае да го изпълва със смисъл (макар при връщането на имената на българските турци в документите да е изписано Абдул Самед Вели – по настояване на чиновничката, с която е предпочел да не спори).

От 2010 г. живее във Франция със семейството си, но е в ежедневна връзка с България и най-вече с пловдивския квартал „Столипиново“ заради каузата, на която се е посветил – онлайн медията „Филибелии. Гласът на „Столипиново“, на която е главен редактор. Платформата е неговата малка човешка битка срещу маргинализирането на общности на етнически принцип. Въпреки държавните стратегии за социално включване реалността остава тревожна. Малцинствените групи са държани в изолация, а разделението започва още от раждането и минава през сегрегирането в детските градини, училищата, докато се стигне до отношението на институциите към зрелия индивид.

В своя статия Абдулсамед Вели пише за болезнената реалност, в която израстват поколения наред, чийто живот протича основно в квартала: 

„Младите тук не мечтаят за високи позиции в холдинги. Те мечтаят за място, където да седнат заедно, влюбени, без да се срамуват от мястото, където живеят. Където да запомнят първата целувка, да снимат спомен, който не е на фон от разпадащи се фасади и прашни улици. Но в „Столипиново“ днес няма дори едно такова кътче – няма градинка, няма сцена, няма площадче за любов и мечти. И въпреки това хората не стоят със скръстени ръце. В квартала кипи живот – вътрешна търговия, малки бизнеси, магазини, работилници. Те сами са изградили икономика, която им помага да оцелеят. Но няма как сами да решат големите проблеми.“

В най-ранните си детски години Абдулсамед Вели е живял в различни пловдивски квартали, но преди да тръгне на училище, семейството му се премества в кв. „Столипиново“. Учи в обединено училище (ОбУ „Пенчо Славейков“), в което баща му работи като охрана. В него се акцентира върху професионалното обучение за сметка на общообразователните предмети. Вели не успява да завърши средно образование – по време на хиперинфлацията през 1996–1997 г. майка му е съкратена от фабриката, в която работи, и вкъщи остават без средства. Затова започва работа на 16 години. 

Жени се през 2001 г. След шест години очакване на дете със съпругата му решават да си осиновят, но две години по-късно се ражда дъщеря им. Сега тримата живеят във Франция. Вкъщи говорят основно на турски, а дъщеря му е изцяло оформена от френската образователна система. За нея той с гордост казва, че всяка седмица си взема по една книга от библиотеката и я изчита.

В медията, с която е ангажиран ежедневно, често се публикуват материали, призоваващи хората да инвестират в образованието на децата си – заради бъдещето, което би било възможно само за завършилите университет. Например:

 „Само пет години образование и труд – и тези деца ще носят промяната не само за себе си, но и за семействата си, за махалата, за целия народ […] нашите деца ще бъдат лекари, учители, майстори, програмисти, адвокати.“ 

Абдулсамед Вели вярва, че човек има силите и възможностите да се самосъздаде дори при неравен житейски старт. Затова и в момента е подел нова инициатива – търси младеж или девойка с малцинствен произход, без един или двама родители, който или която мечтае да следва висше юридическо образование, но няма финансовата възможност да го направи: 

„Ако познавате амбициозен млад човек, с желание да стане юрист, адвокат или защитник на справедливостта – моля, свържете го с мен. Готов съм лично да поема разходите по обучението му в университета. Кандидатът трябва да предостави документ, че е сирак или полусирак.“


На какво Ви научи Франция?

Да съм по-спокоен, да съм по-търпелив и да не прибързвам. Да съм по-уверен. А може да е и от възрастта ми. На Франция дължа и живота си – през 2020 г. ми откриха рак на бъбрека, тук ме оперираха и ми спасиха живота. Отношението на местното население и на институциите към всички хора тук е еднакво.

Преместих се във Франция заради културата ѝ, а не заради финансовите възможности, които страната дава. По това време в България имах хранителен магазин, работех към енергоразпределително дружество и допълнително бях кредитен консултант. Влюбих се във всичко, което прочетох в тринайсетте тома на „Рокамбол“ от Понсон дю Терай. Тук научих и че в Турция има закон, който позволява да получиш безсрочна турска лична карта, ако можеш да докажеш произход. В българската система за гражданска регистрация ЕСГРАОН и аз, и родителите ми сме записани като турци. И това важи за много семейства, макар че мнозина ни възприемат като роми. Не знам дали не се дължи и на факта, че за интеграция на ромите общините в България получават финансиране. Да, културата ни е смесена, особено в квартали като „Столипиново“, но етническият произход е различен.

Да поговорим за интеграцията. Каква промяна мечтаете да настъпи в обществото по отношение на малцинствата и каква в другата посока – на хората от малцинствените групи към обществото?

Мисля, че в България правилната дума трябва да е „адаптация“, защото интеграцията е за чужденците, за имигрантите. А ние сме тук от векове, живеем заедно. Но сякаш институциите, пък и училището ни възприемат като чужди.

Като стартов етап трябва да се променят политиците и хората, които представляват институциите и обществото. И медиите в това число. Да променят начина, по който се говори за малцинствата. Създава се един негативен образ, снимат се бедни и окъсани деца, сякаш ние сме тези, които не искаме да се променим. От друга страна, много хора в квартала не забелязват тънките разлики в езика и не разбират, че по някакъв начин са били унижени. В коментарите онлайн пък и българи, и хора от квартала използват едни към други език на омразата. Ето така се създава разделение на етнически принцип. Имаме закони, но никой не ги прилага.

На този етап промяната в квартал „Столипиново“ и навсякъде сред малцинствата може да стане единствено чрез образование. А също и хората да спрат да вярват на местните лидери и при проблем да се обръщат към институциите.

По едно си приличаме – в България почти всички, без значение от етническия произход, сме мързеливи. Също и по отношение на образованието.

Какво мислите за изкуствата? Нямаме ли нужда в училище от повече часове по изкуства?

Да, изкуството променя светогледа. Според моята религия например не е позволено да се рисува, но дъщеря ми рисува, тя се изразява чрез пеене, писане и рисуване. Когато аз бях дете, ни водеха на театър. Също така много харесвам програмите за обмен на ученици. Моето дете например беше в Испания, в испанско семейство, и сега има приятелка там, непрекъснато се чуват.

Разкажете ни и за Вашето детство, с какво го свързвате?

Много игри навън, пред блока. С брат ми имаме година и пет месеца разлика във възрастта и все ни се караха да се прибираме. В събота и неделя, както и през лятната ваканция, бяхме при роднини в съседния квартал „Тракия“, където имахме приятели българи. Там децата растяха заедно. Най-вкусната храна и досега за мен са бял фасул и пилаф, любимите ми от детството. А през зимата – и люта туршия. Сега във Франция цялото ми семейство без люто също не сяда на масата.

Научих се да чета и пиша на турски на четиригодишна възраст. По-късно научих българската азбука. Преди 1989 г. жените тайно се събираха да четат молитви в някой апартамент и баба ми ме водеше, знам си молитвите още оттогава. Турският език беше забранен, но ние тайно си говорехме – и вкъщи, и на улицата, ако нямаше милиция. 

Спомням си, че през зимата беше забранено да се излиза на улицата след 20 ч. Мен веднъж ме спря милицията, аз се прибирах много късно от баба ми, през няколко блока живеехме. Крещяха ми, но нищо не ми направиха – аз бях още дете и проявиха разбиране. Но се страхувахме, бяхме възпитавани в страх.

Във Ваша статия във „Филибелии“ ясно сте очертал примката, в която е стегнат мултиетнически квартал като „Столипиново“: „Канализация има, но няма чистота, липсва нужната инфраструктура, качествено образование и институционална подкрепа. И не защото хората не искат да живеят достойно […] политическата воля, както знаем, се появява само когато носи дивидент. Всяка власт досега е използвала „Столипиново“ като оправдание.“

Боя се, че нямаме политически лидери – има подставени хора, които печелят изборите срещу заплащане. Трябва да имаме предвид и манталитета на хората тук. С десетилетия се създава образ на безнаказаността на лидерите. Повечето жители на квартала се притесняват от агресия. Преди години имаше единство, знаеха се големите родове в „Столипиново“ и хората се чувстваха защитени. След пандемията обаче светът се промени наистина, в квартала също – отношенията между хората са различни, те вече не са така социализирани, не общуват толкова помежду си. 

Религията обаче промени доста семейства в положителна насока. През 90-те години много хора пиеха алкохол, биеха се по сватби и тържества, бяха доста агресивни. Сега са по-умерени, ходят на месджид за молитва. Впрочем в целия арабски свят и в бившите съветски републики така се наричат джамиите, ние сме възприели турската дума „джамия“.

От какво се притесняват хората в квартала по Ваши наблюдения?

Че държавата и институциите са ги оставили сами. Хората в квартала няма как да се защитят при агресия и не могат да разчитат особено на полиция и прокуратура. По-културните семейства, по-образованите и по-независимите финансово се опитват вече да избягат в друг район или по селата, както и в чужбина.

Смятате ли, че в малцинствените общности нарочно се развиват зависимости към политически проекти или партии?

Ако погледнем исторически, от етническите махали до цели държави и региони трябва да са зависими от някого. Хората, разделени по общности или заради идеология, са по-лесни за манипулиране. „Разделяй и владей.“ 

Как Ви хрумна идеята да създадете Вашата медия „Филибелии. Гласът на „Столипиново“?

По време на затварянето заради COVID-19 създадох Facebook групата „Жители на Столипиново“ (между другото, по време на локдауна партиите ДПС и ДОСТ водиха всичките си предизборни кампании в моята група). Много хора тогава изгубиха работата си и средствата си за препитание. Ние направихме кампания за набиране на средства от чужбина. Регистрирахме сдружение, за да могат доброволците да излизат от квартала, да купуват хранителни и други продукти. Започнахме да събираме и раздаваме помощи при пълна прозрачност, с отчети в групата [и до днес такива кампании ежемесечно вървят на страницата на „Филибелии“ – б.а.]. И тогава осъзнах, че има нужда от такава медия.

А сега ни предстои да запишем и подкаст по темата за образованието, защото тя наистина е главната. Инициативата е на „Филибелии“.


Хората, които тихо и кротко променят средата, в която живеят, формират общности и задават посоки, в които има смисъл да тръгнем заедно. Тук ви срещаме с тях. Това са „Тези хора“.

The state of SSL stacks

Post Syndicated from corbet original https://lwn.net/Articles/1020309/

Willy Tarreau and William Lallemand have posted an extensive white
paper
examining the landscape of the available SSL implementations.

OpenSSL 3.0 performs significantly worse than alternative SSL
libraries, forcing organizations to provision more hardware just to
maintain existing throughput. This raises important questions about
performance, energy efficiency, and operational costs.

Examining alternatives—BoringSSL, LibreSSL, WolfSSL, and
AWS-LC—reveals a landscape of trade-offs. Each offers different
approaches to API compatibility, performance optimization, and QUIC
support. For developers navigating the modern SSL ecosystem,
understanding these trade-offs is crucial for optimizing
performance, maintaining compatibility, and future-proofing their
infrastructure.

Изоставеното наследство. Защо България не може да продължи да пренебрегва правото на дом

Post Syndicated from Сара Перин original https://www.toest.bg/izostavenoto-nasledstvo-zashto-bulgaria-ne-mozhe-da-produlzhi-da-prenebregva-pravoto-na-dom/

Изоставеното наследство. Защо България не може да продължи да пренебрегва правото на дом

В продължение на десетилетия България пренебрегва едно от основните си жилищни предизвикателства, наследено от комунистическото минало. Докато вниманието е насочено към развитието на бизнеса и икономиката, недовършената жилищна реформа остава до голяма степен неосъществена – особено за бедните и уязвимите общности.

По време на комунистическото управление географската мобилност на хората, тоест движението от едно населено място в друго, е порицавана и насилствено ограничавана. Ромските общности са обект на политиката на комунистическата партия за насилствена уседналост от 1958 г., като за тази цел ромите са назначавани предимно на нискоквалифицирани длъжности в селското стопанство и промишлеността. Целта – заселване и асимилация, а не интеграция. Въпреки гарантираната заетост и осигуреното базово жилище в този период от развитието на българската държава, социално-икономическото неравенство продължава да се възпроизвежда през поколенията.

След срива на социалистическата икономика безработицата рязко нараства – особено сред бедни и уязвими общности като ромите, които са сред първите, останали без препитание. Поддръжката на общински жилища от страна на местните власти и социалните услуги се сриват, а условията в много квартали с неясен правен статут, които вече са нестабилни, се влошават още повече.

Допълнителен проблем е, че множество жилища, построени неофициално още по време на комунистическия режим, така и не са узаконени. Това оставя техните обитатели в състояние на хронична правна несигурност и постоянна заплаха от изселване. В резултат държавата и общините често използват неформалния статут на тези зони като оправдание за липсата на инвестиции в инфраструктура или благоустрояване.

В България по време на прехода към демокрация не беше разработена ясна или всеобхватна „нова социална жилищна политика“. Вместо това се запази наследството на старата политика – принудително заселване без подходяща инфраструктура и често принудително извеждане и разрушаване на единствено жилище, без достойна и справедлива алтернатива. 

Днес в цялата страна съществуват повече от 100 неформални ромски квартала, макар и да липсва официална информация, надлежно документираща това предположение. Вместо да провеждат системна политика за подобряване на условията за живот в тези квартали, властите до голяма степен ги игнорират, като позволяват несигурността да продължи, а в някои случаи и ситуацията да се влоши. Продължителното бездействие създава почва за заблуждаващи представи, които изместват отговорността от общините към самите засегнати общности и така нормализират в очите на мнозинството недопустимите условия за живот. 

Липсата на видимост на бездомността в България създава у обществото погрешното разбиране, че такъв проблем не съществува. Отсъствието на бездомността от дневния ред на обществото обаче не трябва да замъглява факта, че десетки хиляди български граждани живеят в условия на скрита бездомност и постоянна жилищна несигурност.

София не е беден град – с бюджет от 1,32 милиарда евро тя има ресурс да гарантира достойни условия на живот. Но докато пазарът на недвижими имоти върви нагоре, социалните политики изостават. Едно общество расте истински, когато всички имат шанс да вървят напред – както бизнесът, така и хората.

Ситуацията в район „Илинден“ е показателна за това напрежение: Общината не успява активно да подготви достойни за живот алтернативи за уязвимите жители преди разрушаването на единствените им домове. Европейските разпоредби са категорични: семействата, живеещи в неформални селища – особено когато те са резултат от исторически политики на принудително заселване, – имат право на съвременни и достойни жилищни решения. 

На практика неформалните ромски квартали са част от т.нар. обичайно право. Дори в развити страни по отношение на неформални квартали, които съществуват над 100 години без официална регулация, често се прилагат нормите на обичайното право – неписани, но утвърдени правила, възникнали от дългогодишна практика. Те уреждат отношенията между хората – ползване на имоти, строежи, съседски спорове – и се спазват, защото са приети за справедливи и необходими. В някои случаи тези обичаи са признати и от закона. А на територията на днешните неформални ромски квартали, както става ясно от историческата справка, ромите често са били насилствено заселвани. Самите квартали пък се създават и разрастват пред погледа на институциите и с тяхното мълчаливо съгласие. 

Присъствието на ромски общности в България не е ново явление. Исторически записи от 1400 г. и османски данъчни регистри от 1500 г. документират съществуването им. В исторически план номадството или движението на хора и стоки в империята е било регулирано, но прието. Едва в средата на ХХ в. принудителното заселване се превръща в официална политика.

По време на Прехода политиките за реституция на земя даваха приоритет на частните претенции, като често пропускаха общности, заселени на общинска земя. В резултат на това много ромски общности бяха оставени в ситуация на правна несигурност, уязвими на заповеди за събаряне. Между 2012 г. и 2017 г. 89% от заповедите за събаряне са насочени към единственото жилище на ромско семейство, като по този начин се оставят много деца, възрастни и болни хора без сигурен дом. 

Жилищната несигурност не е изолиран проблем. Тя е тясно свързана с бедността, която се предава от поколение на поколение. Днес повече от половината роми в България живеят в нерегламентирани квартали, където 80% от жителите нямат канализация и топла вода. Жилищната нестабилност увеличава хроничния стрес и има документирано въздействие върху образователните резултати. Тези обстоятелства може да помогнат за обяснението на поне една от причините, поради които продължават да съществуват разлики в дела на завършилите училище по етнос – само 23% от ромските ученици получават средно образование, а по-малко от 2,6% продължават в университет.

За съжаление, българската общественост често продължава да се противопоставя на спорадичните усилия на държавата за подобряване на условията на живот в ромските общности. Причините са устойчиви стереотипи, негативни нагласи и погрешни схващания за ромите и тяхното положение. Тази широко разпространена съпротива допринася за продължаващото нежелание на държавните и местните органи да се ангажират смислено с проблема, а това от своя страна засилва циклите на изключване и маргинализация.

София, а и България като цяло трябва да приемат модерна социална жилищна политика – такава, която да отразява европейските стандарти за достойнство, приобщаване и възможности. В Европа вече съществуват успешни модели. Например финландският подход „Първо жилище“ дава приоритет на осигуряването на стабилно постоянно жилище като основа преди решаването на други социални проблеми, което значително намалява бездомността в цялата страна. 

„Тръст за социална алтернатива“ също така успешно въведе иновативен модел в три общини в България, при който местните общини работят с жители, архитекти и геодезисти за регулация на съществуващите квартали. Дългосрочната цел е семействата да станат собственици на жилища и да плащат данъци – нещо, за което много от живеещите там мечтаят: да бъдат третирани и възприемани като граждани. Подобни принципи биха могли да ръководят българските усилия за предлагане на регламентирани жилища на достъпни цени на уязвими семейства или за работа с тях за регулация на отдавна заселените квартали и общности.

Една просперираща европейска столица трябва да е в състояние едновременно да защитава и бизнес интересите на частни инвеститори или публични власти, и най-уязвимите си граждани. 

Решаването на проблема с наследството от принудителното заселване чрез цялостна стратегия за социални жилища е не само морален императив, но и предпоставка за устойчиво и приобщаващо развитие. Достъпното жилище за всички български граждани в уязвимо положение е важна основа, която предопределя пътя на всеки човек към достоен живот. То променя житейските перспективи и укрепва социалното сближаване. България може да бъде силна само със силни граждани.

Времето за бездействие изтече. България разполага както с ресурсите, така и с експертността да предприеме решителни стъпки. Модернизирането на социалната жилищна политика не е избор – то е отговорност. София трябва да даде пример и да изпълни обещанието си за истинска европейска столица – такава, която отстоява достойнството и правата на всички свои граждани.


Статията е изготвена със съдействието на Мария Методиева и Огнян Исаев.

The end of the USENIX Annual Technical Conference

Post Syndicated from corbet original https://lwn.net/Articles/1020306/

On the 50th anniversary of the USENIX organization, its flagship Annual
Technical Conference (ATC) is coming
to an end
.

For the past two decades, as more USENIX conferences have joined
the USENIX calendar by focusing on specific topics that grew out of
ATC itself, attendance at ATC has steadily decreased to the point
where there is no longer a critical mass of researchers and
practitioners joining us. Thus, after many years of experiments to
adapt this conference to the ever-changing tech landscape and
community, the USENIX Board of Directors has made the difficult
decision to sunset USENIX ATC.

Many important technologies first saw the light of day at this event.

The OCP DC-SCM HFF is Taking Over Our Guide

Post Syndicated from John Lee original https://www.servethehome.com/the-ocp-dc-scm-hff-is-taking-over-our-guide-asus-dell-supermicro-gigabyte-flex-wistron/

The OCP DC-SCM HFF is taking over the server industry, providing a new degree of flexibility in adding BMC and security to server systems

The post The OCP DC-SCM HFF is Taking Over Our Guide appeared first on ServeTheHome.

Accelerate the transfer of data from an Amazon EBS snapshot to a new EBS volume

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/accelerate-the-transfer-of-data-from-an-amazon-ebs-snapshot-to-a-new-ebs-volume/

Today we are announcing the general availability of Amazon Elastic Block Store (Amazon EBS) Provisioned Rate for Volume Initialization, a feature that accelerates the transfer of data from an EBS snapshot, a highly durable backup of volumes stored in Amazon Simple Storage Service (Amazon S3) to a new EBS volume.

With Amazon EBS Provisioned Rate for Volume Initialization, you can create fully performant EBS volumes within a predictable amount of time. You can use this feature to speed up the initialization of hundreds of concurrent volumes and instances. You can also use this feature when you need to recover from an existing EBS Snapshot and need your EBS volume to be created and initialized as quickly as possible. You can use this feature to quickly create copies of EBS volumes with EBS Snapshots in a different Availability Zone, AWS Region, or AWS account. Provisioned Rate for Volume Initialization for each volume is charged based on the full snapshot size and the specified volume initialization rate.

This new feature expedites the volume initialization process by fetching the data from an EBS Snapshot to an EBS volume at a consistent rate that you specify between 100 MiB/s and 300 MiB/s. You can specify this volume initialization rate at which the snapshot blocks are to be downloaded from Amazon S3 to the volume.

With specifying the volume initialization rate, you can create a fully performant volume in a predictable time, enabling increased operational efficiency and visibility on the expected time of completion. If you run utilities like fio/dd to expedite volume initialization for your workflows like application recovery and volume copy for testing and development, it will remove the operational burden of managing such scripts with the consistency and predictability to your workflows.

Get started with specifying the volume initialization rate
To get started, you can choose the volume initialization rate when you launch your EC2 instance or create your volume from the snapshot.

1. Create a volume in the EC2 launch wizard
When launching new EC2 instances in the launch wizard of EC2 console, you can enter a desired Volume initialization rate in the Storage (volumes) section.

You can also set the volume initialization rate when creating and modifying the EC2 Launch Templates.

In the AWS Command Line Interface (AWS CLI), you can add VolumeInitializationRate parameter to the block device mappings when call run-instances command.

aws ec2 run-instances \
    --image-id ami-0abcdef1234567890 \
    --instance-type t2.micro \
    --subnet-id subnet-08fc749671b2d077c \
    --security-group-ids sg-0b0384b66d7d692f9 \
    --key-name MyKeyPair \
    --block-device-mappings file://mapping.json

Contents of mapping.json. This example adds /dev/sdh an empty EBS volume with a size of 8 GiB.

[
    {
        "DeviceName": "/dev/sdh",
        "Ebs": {
            "VolumeSize": 8
            "VolumeType": "gp3",            
            "VolumeInitializationRate": 300
		 } 
     } 
]

To learn more, visit block device mapping options, which defines the EBS volumes and instance store volumes to attach to the instance at launch.

2. Create a volume from snapshots
When you create a volume from snapshots, you can also choose Create volume in the EC2 console and specify the Volume initialization rate.

Confirm your new volume with the initialization rate.

In the AWS CLI, you can use VolumeInitializationRate parameter and when calling create-volume command.

aws ec2 create-volume --region us-east-1 --cli-input-json '{
    "AvailabilityZone": "us-east-1a",
    "VolumeType": "gp3",
    "SnapshotId": "snap-07f411eed12ef613a",
    "VolumeInitializationRate": 300
}'

If the command is run successfully, you will receive the result below.

{
    "AvailabilityZone": "us-east-1a",
    "CreateTime": "2025-01-03T21:44:53.000Z",
    "Encrypted": false,
    "Size": 100,
    "SnapshotId": "snap-07f411eed12ef613a",
    "State": "creating",
    "VolumeId": "vol-0ba4ed2a280fab5f9",
    "Iops": 300,
    "Tags": [],
    "VolumeType": "gp2",
    "MultiAttachEnabled": false,
    "VolumeInitializationRate": 300
}

You can also set the volume initialization rate when replacing root volumes of EC2 instances and provisioning EBS volumes using the EBS Container Storage Interface (CSI) driver.

After creation of the volume, EBS will keep track of the hydration progress and publish an Amazon EventBridge notification for EBS to your account when the hydration completes so that they can be certain when their volume is fully performant.

To learn more, visit Create an Amazon EBS volume and Initialize Amazon EBS volumes in the Amazon EBS User Guide.

Now available
Amazon EBS Provisioned Rate for Volume Initialization is now available and supported for all EBS volume types today. You will be charged based on the full snapshot size and the specified volume initialization rate. To learn more, visit Amazon EBS Pricing page.

To learn more about Amazon EBS including this feature, take the free digital course on the AWS Skill Builder portal. Course includes use cases, architecture diagrams and demos.

Give this feature a try in the Amazon EC2 console today and send feedback to AWS re:Post for Amazon EBS or through your usual AWS Support contacts.

— Channy


How is the News Blog doing? Take this 1 minute survey!

(This survey is hosted by an external company. AWS handles your information as described in the AWS Privacy Notice. AWS will own the data gathered via this survey and will not share the information collected with survey respondents.)

The collective thoughts of the interwebz