gnome-keyring-daemon không thể phân bổ bộ nhớ an toàn


8

Tôi chạy logcheck trên hệ thống Debian Linux của mình để được cảnh báo về các dòng bất thường trong các tệp nhật ký của mình và gần đây tôi đã thấy như sau /var/log/messages:

gnome-keyring-daemon: couldn't allocate secure memory to keep passwords and or keys from being written to the disk

Tôi không biết chính xác những gì gây ra tin nhắn, chỉ cần nhận thấy nó sau đó trong nhật ký. Điều này có nghĩa là gì, và làm thế nào tôi có thể sửa nó?

Câu trả lời:


12

Gnome-keyring-daemon không thể phân bổ bộ nhớ không thể hoán đổi (đó là cái mà nó gọi là bộ nhớ bảo mật An-mật). Lý do nó cố gắng làm điều đó là việc viết dữ liệu nhạy cảm (mật khẩu hoặc khóa) để trao đổi là một rủi ro. Tuy nhiên, đó chỉ là rủi ro đối với một mối đe dọa cụ thể: mối đe dọa rằng ai đó sẽ đánh cắp đĩa của bạn, nhưng không phải là máy tính hỗ trợ của bạn. Sẽ không liên quan nếu bạn không có không gian hoán đổi hoặc mã hóa không gian hoán đổi của mình. Nó cũng không liên quan nếu máy tính của bạn ở một vị trí an toàn về mặt vật lý. Nó có liên quan nếu máy tính của bạn là máy tính xách tay và bạn lo lắng về một tên trộm không tinh vi, nhưng những tên trộm không tinh vi có xu hướng quan tâm đến giá trị bán lại của máy tính xách tay của bạn và không phải mật khẩu của bạn (tuy nhiên, có một thị trường đang phát triển để bán lại mật khẩu của công ty). Nếu bạn lo lắng về những tên trộm tinh vi,

Việc phân bổ bộ nhớ không thể hoán đổi được thực hiện bằng lệnh mlockgọi hệ thống, khóa trang bộ nhớ tại vị trí thực tế hiện tại của nó. Điều này đòi hỏi đặc quyền vì nếu không một ứng dụng có thể bão hòa RAM. Trong Linux , đặc quyền thích hợp là khả năng . Dưới Solaris , nó .CAP_IPC_LOCK PRIV_SYS_CONFIG

Trong Linux, bất kỳ quy trình nào cũng có thể khóa một lượng nhỏ bộ nhớ, được xác định theo RLIMIT_MEMLOCKgiới hạn. Trong hầu hết các shell, ulimit -lsẽ hiển thị bao nhiêu bộ nhớ mà mỗi quá trình không có đặc quyền có thể khóa (tính bằng kB). Nếu giới hạn là 0, hãy kiểm tra xem đó là giới hạn cứng (áp đặt bởi root, được liệt kê với ulimit -Hl) hay giới hạn mềm (tự áp đặt, được liệt kê bởi ulimit -Sl). Bạn có thể nâng giới hạn mềm lên đến giới hạn cứng bằng vd ulimit -l 64. Để tăng giới hạn cứng, chỉnh sửa /etc/security/limits.conf(cú pháp được ghi lại trong tệp); tập tin này được đọc khi bạn đăng nhập.

TL, DR: đó là một tính năng bảo mật mà bạn có thể không quan tâm. Đừng đổ mồ hôi.


0

Tôi vừa nhận được những tin nhắn này trên Ubuntu 18.04 và hóa ra vì lý do nào đó apparmorđã ngừng bắt đầu khởi động. Bắt đầu apparmor, đăng xuất và đăng nhập lại một lần nữa sẽ sửa nó tạm thời hoặc bật apparmorlại khi khởi động và khởi động lại cũng sửa nó.

Vì vậy, nếu nó đang hoạt động và sau đó dừng lại, có lẽ bạn cần tìm hiểu tại sao bộ nhớ này không còn có thể được phân bổ nữa (vì vậy sự trợ giúp ở trên, apparmor, selinux, v.v.).


-2

Tôi cũng có:

Oct 20 22:43:28 gnome-keyring-daemon[13543]: Gkm: using old keyring directory: /home/sergio/.gnome2/keyrings
Oct 20 22:43:28  gnome-keyring-daemon[13543]: Gkm: using old keyring directory: /home/sergio/.gnome2/keyrings
Oct 20 22:49:13  gnome-keyring-daemon[13543]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk

Giải pháp duy nhất mà tôi tìm thấy là bắt đầu một khóa mới từ đầu mất mật khẩu đã lưu trong lần khóa trước.
Tôi đã xóa .gnome2 / keyrings và tôi đã mất tất cả mật khẩu của mình nhưng gnome đã tạo một thư mục mới với các chuỗi khóa trong .local / share / keyrings, và các cảnh báo biến mất.

bạn có thể chỉnh sửa mật khẩu bằng lệnh seahorse

Tôi đã có một vài mật khẩu vì vậy tôi không phiền, nhưng một khi tôi di chuyển thư mục .gnome2 / keyrings thì tôi không bao giờ lấy lại được mật khẩu của mình. Và giải quyết vấn đề


2
bị hạ thấp vì giải pháp gây mất dữ liệu khi thực sự không phải là vấn đề lớn (xem câu trả lời của Gilles). Ngoài ra, tôi nghi ngờ rằng điều này sẽ khắc phục một triệu chứng, không phải là nguyên nhân gốc rễ.
strugee

không, bạn nên di chuyển khóa gnome, tôi không biết làm thế nào và tôi cảnh báo rằng dữ liệu sẽ bị mất.
Sérgio
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.